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Reception of channel allocation on assigned channel 830 
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augmented channel allocation" 837 

CLCH(-Q) permission 838 

Monitoring pattern information 839 

Bandwidth, modulation mode and related parameters 839 

Napping status and napping information 840 

Elements following napping status and napping information 840 

Usage marker assignment 841 

Maintenance of assigned channel 842 

Criteria for leaving assigned channel 842 

Checking of AACH or AACH-Q 842 

Inactivity time-out 844 

Criteria for leaving carrier specific signalling channel 845 

Traffic on downlink for other users 846 

Maintenance of common channel 847 

PDU transfer for broadcast messages (TMB-SAP) 847 
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28.4.4.7 SN-DEACTIVATE PDP CONTEXT DEMAND 996 

28.4.4.8 SN-DEACTIVATE PDP CONTEXT ACCEPT 997 

28.4.4.9 SN-ENDOFDATA 997 

28.4.4.9a SN-MODIFY PDP CONTEXT REQUEST 998 

28.4.4.9b SN-MODIFY PDP CONTEXT RESPONSE 998 

28.4.4.9c SN-MODIFY PDP CONTEXT AVAILABILITY 999 

28.4.4.9d SN-MODIFY PDP CONTEXT USAGE 999 

28.4.4.10 SN-NOT SUPPORTED 1000 

28.4.4.1 1 SN-P AGE REQUEST 1000 

28.4.4.12 SN-P AGE RESPONSE 1001 
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28.4.4.14 SN-UNITDATA 1002 
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28.4.5.1 Accept/Reject 1003 
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28.4.5.4a Asymmetrical QoS 1005 

28.4.5.4 b Background class request 1005 

28.4.5.5 BSD data compression parameters 1005 
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28.4.5.7 BSD dictionary size 1005 

28.4.5.7a CONTEXT_READY timer 1006 

28.4.5.7b Data class 1006 

28.4.5.7c Data priority details 1006 

28.4.5.7d Data priority random access delay factor 1007 

28.4.5 .7e Data priority request result 1007 

28.4.5 .7f Data priority request type 1007 

28.4.5.7g Data priority sub-type 1007 
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28.4.5.8a Delay class 1008 

28.4.5.9 DCOMP 1008 

28.4.5.10 DCOMP negotiation 1008 

28.4.5.11 Deactivation type 1009 

28.4.5.11a Diffserv filter 1009 

28.4.5.12 Enhanced 7t/4-DQPSK service 1009 

28.4.5.13 Immediate service change 1009 

28.4.5.14 IP address Ipv4 1009 

28.4.5.15 Largest header size in octets that maybe compressed 1010 

28.4.5.15a Layer 2 data priority lifetime 1010 

28.4.5.15b Layer 2 data priority signalling delay 1010 

28.4.5.16 Logical link status 1010 

28.4.5.17 Maximum interval between full headers 1011 
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28.4.5.19a Mean active throughput 1012 

28.4.5.19b Mean throughput 1012 

28.4.5.19c Minimum peak throughput 1013 

28.4.5. 19d Modification reject cause 1013 

28.4.5. 19e Modification resuh 1013 

28.4.5. 19f Modify sub-type 1014 

28.4.5. 19g MS default data priority 1014 

28.4.5. 19h MS default data priority flag 1014 

28.4.5.191 Network defauh data priority 1014 

28.4.5.20 Not supported SN PDU type 1015 

28.4.5.21 N-PDU 1015 

28.4.5.22 NSAPI 1015 

28.4.5.23 Number of compression state slots, TCP 1015 
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28.4.5.26 Packet data MS Type 1016 

28.4.5.27 PCOMP 1016 
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28.4.5.28 PCOMP negotiation 1017 
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28.4.5.30 PDU priority max 1018 
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28.4.5.31d QoS filter operation 1020 

28.4.5.31e QoS filter type 1021 

28.4.5.31f QoS set 1021 

28.4.5.32 READY timer 1021 

28.4.5.32a Reliability class 1022 

28.4.5.33 Reply requested 1022 

28.4.5.34 Resource request 1023 

28.4.5.35 RESPONSE_W AIT timer 1024 

28.4.5.35a Scheduled access 1025 

28.4.5.35b Scheduled access information included 1025 

28.4.5.36 SNDCP version 1026 

28.4.5.37 SNDCP network endpoint identifier 1026 

28.4.5.38 SN PDU type 1026 

28.4.5.39 STANDBY timer 1027 

28.4.5.40 SwMI IPv6 Information 1027 

28.4.5.41 SwMI Mobile IPv4 Information 1028 

28.4.5.42 Transmit response reject cause 1028 

28.4.5.43 Type identifier in accept 1028 

28.4.5.44 Type 3 element identifier 1029 

28.4.5.45 V.42bis compression request, Pq 1029 

28.4.5.46 V.42bis data compression parameters 1029 

28.4.5.47 V.42bis maximum string length, P2 1029 
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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Terrestrial 
Trunked Radio (TETRA). 

The present document is part 2 of a multipart deliverable covering the Terrestrial Trunked Radio (TETRA); Voice plus 
Data (V+D), Release 2, as identified below: 

EN 300 392-1: "General network design"; 

TS 100 392-2: "Air Interface (AI)"; 

EN/TS 300 392-3: "Interworking at the Inter-System Interface (ISI)"; 

ETS 300 392-4: "Gateways basic operation"; 

TS 300 392-5: "Peripheral Equipment Interface (PEI)"; 

TS 300 392-7: "Security"; 

EN 300 392-9: "General requirements for supplementary services"; 

EN 300 392-10: "Supplementary services stage 1"; 

EN 300 392-11: "Supplementary services stage 2"; 

EN 300 392-12: "Supplementary services stage 3"; 

ETS 300 392-13: "SDL model of the Air Interface (AI)"; 

ETS 300 392-14: "Protocol Implementation Conformance Statement (PICS) proforma specification"; 

TS 100 392-15: "TETRA frequency bands, duplex spacings and channel numbering"; 

TS 100 392-16: "Network Performance Metrics"; 

TR 100 392-17: "TETRA V+D and DMO specifications"; 

TS 100 392-18: "Air interface optimized applications". 

NOTE: Part 10, sub-part 15 (Transfer of control), part 13 (SDL) and part 14 (PICS) of this multi-part deUverable 
are in status "historical" and are not maintained. 
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Introduction 



The present document adds the specifications due to maintenance of the version V3.2.1of the Voice+Data Air Interface 
standard TS 100 392-2. The main additions are: 

• Updates to the MEX layer; 

• Updated to the SNDCP layer; 

• Updates to the MLE layer. 



£75/ 



41 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 



Scope 



The present document defines the Air Interface (AI) for the Terrestrial Trunked Radio (TETRA) system supporting 
Voice plus Data (V+D) and contains the specifications of the physical layer, the data link layer and the network layer 
according to the ISO model. 

First, it establishes the TETRA radio aspects (layer 1): 

• it defines and specifies the modulation; 

• it defines and specifies the radio transmission and reception; 

• it defines and specifies the synchronization; 

• it defines and specifies the channel coding; 

• it defines and specifies the channel multiplexing; 

• it defines and specifies the control over the radio link. 

Secondly, it establishes the services, messages and protocols used for voice and circuit mode data transfer, starting with 
the upper layers: 

• it defines and specifies the services provided by the CC sub-entity; 

• it defines and specifies the services provided by the SS sub-entity; 

• it defines and specifies the services provided by the SDS sub-entity; 

• it defines and specifies the protocol used by the Circuit Mode Control Entity (CMCE) to communicate across 
the air interface in order to offer the services of the Call Control (CC), Supplementary Service (SS) and Short 
Data Service (SDS) sub-entities; 

• it defines and specifies the services and protocol used for the management of the users' mobility inside and 
across TETRA networks, namely the ones of the Mobility Management (MM) entity and the MLE; 

• it defines and specifies the services and protocol used in the data link layer subdivided in two sub-entities, the 
Logical Link Control (LLC) and the Medium Access Control (MAC) entities. 

Thirdly, it establishes the services, messages and protocols used for packet data transfer: 

• it defines and specifies the services provided by the Sub-Network Specific Data Control Protocol (SNDCP) 
sub -entity; 

• it defines and specifies the protocol used by Sub-Network Specific Data Control Protocol (SNDCP). 
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References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 100 900: "Digital cellular telecommunications system (Phase 2+) (GSM); Alphabets and 
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for end-to-end encryption" . 

[4] ETSI EN 300 113-1: "Electromagnetic compatibiHty and Radio spectrum Matters (ERM); Land 

mobile service; Radio equipment intended for the transmission of data (and/or speech) using 
constant or non-constant envelope modulation and having an antenna connector; Part 1 : Technical 
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[5] ETSI ETS 300 125: "Integrated Services Digital Network (ISDN); User-network interface data 
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[7] ETSI EN 300 392-5: "Terrestrial Trunked Radio (TETRA); Voice plus Data (Vh-D); 
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[8] ETSI EN 300 392-7: "Terrestrial Trunked Radio (TETRA); Voice plus Data (Vh-D); 
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[9] ETSI EN 300 392-9: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); 

Part 9: General requirements for supplementary services". 
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[15] ETSI EN 300 392-12-10: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); 

Part 12: Supplementary services stage 3; Sub-part 10: Priority Call (PC)". 

[16] ETSI EN 300 392-12-16: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); 

Part 12: Supplementary services stage 3; Sub-part 16: Pre-emptive Priority Call (PPC)". 

[17] ETSI EN 300 392-12-22: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); 

Part 12: Supplementary services stage 3; Sub-part 22: Dynamic Group Number Assignment 
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[20] ETSI TS 100 392-18-2: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); 

Part 18: Air interface optimized applications; Sub-part 2: Network Assisted Positioning (NAP)". 

NOTE: At the time of writing ETSI TS 100 392-18-2 specification was in preparation. 

[21] ETSI EN 300 395-2: "Terrestrial Trunked Radio (TETRA); Speech codec for full-rate traffic 

channel; Part 2: TETRA codec". 

[22] ETSI EN 300 396-3: "Terrestrial Trunked Radio (TETRA); Technical requirements for Direct 

Mode Operation (DMO); Part 3: Mobile Station to Mobile Station (MS-MS) Air Interface (AI) 
protocol". 

[23] ETSI EN 300 396-4: "Terrestrial Trunked Radio (TETRA); Technical requirements for Direct 
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[28] ITU-T Recommendation X.25: "Interface between Data Terminal Equipment (DTE) and Data 

Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to 
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[29] IETF RFC 1 144: "Compressing TCP/IP Headers for Low-Speed Serial Links" . 

[30] IETF RFC 1 66 1 : "The Point-to-Point Protocol (PPP)" . 
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[37] IETF RFC 2865: "Remote Authentication Dial In User Service (RADIUS)". 
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[39] IETF RFC 3344: "IP Mobility Support for IPv4". 
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sets". 
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Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 



[i.l] 
[i.2] 

[i.3] 

[i.4] 



ETSI TR 102 300-5: "Terrestrial Trunked Radio (TETRA); Voice plus Data (Vh-D); Designers' 
guide; Part 5: Guidance on Numbering and addressing". 

ETSI TS 144 012: "Digital cellular telecommunications system (Phase 2+); Short Message Service 
CeU Broadcast (SMSCB) support on the mobile radio interface; (3GPP TS 44.012 version 7.0.0 
Release 7)". 

ETSI EN 300 392-3-5: "Terrestrial Trunked Radio (TETRA); Voice plus Data (Vh-D); 

Part 3: Interworking at the Inter-System Interface (ISI); Sub-part 5: Additional Network Feature 

for Mobility Management (ANF-ISIMM)". 

ETSI ETS 300 392-10-7: "Terrestrial Trunked Radio (TETRA); Voice plus Data (Vh-D); 
Part 10: Supplementary services stage 1; Sub-part 7: Short number addressing". 
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[i.9] Open Mobile Alliance, Ltd. Technical_WAP2_0_20021 106: "The WAP 2.0 conformance release". 

NOTE: Available at http://www.openmobilealliance.or.g/tech/affiliates/wap/wapindex.html#wap20 . 
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Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service 
description; Stage 1 (3GPP TS 22.060)". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

access code: subdivision of mobiles for random access opportunities 

acknowledged data transfer: service provided by the layer below which gives an acknowledgement back over the air 
interface from the lower layer peer entity 

NOTE: This service is used by the layer 3 entities to get a secure transmission including retransmissions. 

advanced link: bidirectional connection oriented path between one MS and a BS with provision of acknowledged and 
unacknowledged services, windowing, segmentation, extended error protection and choice among several throughputs 

NOTE: The advance link requires a set-up phase. 

announced cell reselection: cell reselection where MS-MLE informs the SwMI both in the old cell (leaving cell) and 
in the new cell (arriving cell) that cell change is performed 

NOTE: There can be three types of announced cell reselection: 

■ type 1: the MS-MLE knows the new cell and the traffic channel allocations on the cell before 
deciding to leave its serving cell; 

■ type 2: the MS-MLE knows the new cell before changing to it, but does not know the channel 
allocation on the new cell in advance; 
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■ type 3: the MS-MLE needs not to know the new cell before changing to it. The old cell is only 
informed by the MS-MLE that it wants to change cell. 

TETRA V+D may support all three types of announced cell reselection. 

assigned channel: channel allocated by the infrastructure to certain MSs using channel allocation command(s) 
addressed to those MSs 

NOTE: An assigned channel may be allocated for secondary control purposes or for a circuit mode call. 

Associated Control Channel (ACCH): dedicated signalling channel associated with a channel that has been assigned 
for circuit mode traffic 

NOTE: It comprises the Fast Associated Control Channel (FACCH) which uses frames 1 to 18 when there is no 
traffic in a given direction or the Slow Associated Control Channel (SACCH) which is always available 
in frame 18 when there is traffic. 

attached: MS is said to be attached to a cell when the MS is camped and registered on the cell 

NOTE: The MS may be in idle mode (i.e. not actively processing a transaction) or in active mode (i.e. actively 
processing a transaction in reception and/or in transmission). It is the MM which decides when a MS is 
said to be attached. 

background measurement: measurements performed by the lower layers while maintaining current service toward the 
service users, i.e. MS-MLE 

basic link: bidirectional connectionless path between one or several MS and a BS, with a provision of both 
unacknowledged and acknowledged services on a single message basis 

Bit Error Ratio (BER): limit ratio of the bits wrongly received to all bits received in a given logical channel 

broadcast: unidirectional point to multi -point mode of transmission 

C-plane: plane for control and packet data signalling 

call-related service: service requested from call set-up initiation until call disconnection and related to that call 

NOTE: The call-related service can also be valid a certain short time after disconnection but before next call 
set-up is initiated. 

call unrelated service: service either requested outside a call or inside a call but not referring to that call 

called user application: user application which receives an incoming call 

calling user application: user application which initiates an outgoing call 

camped: MS is said to be camped on a cell when the MS is synchronized on the cell BS and has decoded the Broadcast 
Network Channel (BNCH) of the cell 

NOTE: The synchronization procedure is performed by the MAC and the interpretation of the network 

information from the BNCH is performed by a procedure in the MLE. It is the MLE which decides when 
a MS is said to be camped on a cell. 

carrier specific signalling: additional common signalling channel allocated in conjunction with a traffic channel 
specific to the carrier 

cell reselection: act of changing the serving cell from an old cell to a new cell 

NOTE: The cell reselection is performed by procedures located in the MLE and in the MAC. When the 

reselection is made and possible registration is performed, the MS is said to be attached to the cell. 

cell-id: the channel number of the main carrier on the cell 

NOTE: The cell-id as defined here has only a local validity. In TETRA context cell-id may also be another cell 

naming method used in a TETRA network to identify a specific cell independently of the channel number 
of the main charier. 
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common control channels: control channels transmitted by the infrastructure to control the MS population 

NOTE: The common control channels comprise the Main Control Channel (MCCH) and common Secondary 
Control Channels (SCCH). 

concatenated text message: part of a chain of single SDS text messages belonging to a longer text message 

NOTE: Each single SDS text message is concatenated to other SDS text messages using the UDH protocol. 

confirmed service: service provided by the layer below which ensures that a message is responded to by the peer entity 
before new messages are allowed 

NOTE: The service may be used for synchronization of peer entities or for provision of sequential behaviour. 

current serving BS: BS on one of whose channels the MS is currently operating 

D8PSK channel: channel on which signalling and data messages are sent using either 3i/4-DQPSK bursts or 
7I/8-D8PSK bursts. 

data/speech item: all of the functions associated with a complete unidirectional transmission of information during a 
circuit mode call 

NOTE: A call can be made up of one or more call transactions. In a half -duplex call these data/speech items are 
sequential and unidirectional on one user's point of view. 

differentiated services code point: the value of the Differentiated Services (DS) field in IPv4 headers 

NOTE: The differentiated services code point may be used to select the per hop behaviour that an IP packet 
experiences at each node. 

diffserv: the Differentiated Services (DS) field in IPv4 headers 

direct set-up signalling: signalling procedure where immediate communication can take place between the calling and 
the called users without the alerting process and without an explicit response from the called user that he has answered 

dummy call identity: call identity used by MS or LS before the SwMI has allocated a valid call identity 

NOTE: In TETRA the value of the dummy call identity is zero. 
duplex frequency spacing: fixed frequency spacing between up and downlink frequencies directions 

NOTE: The duplex spacing is defined in clause 6 and in TS 100 392-15 [18]. 

foreground measurement: measurements performed by the lower layers while employing the whole capacity, e.g. no 
concurrent service is maintained 

group home SwMI: SwMI which owns the MCC and the MNC of the group identity 

Group TETRA Subscriber Identity (GTSI): an identity used to set up and receive group calls and messages 

NOTE: A TETRA user may have multiple GTSIs associated to its ITSI. Multiple users may have the same GTSI 
as a valid reception address. 

half duplex operation: each MS asks for permission to transmit for each transaction 

NOTE: In TETRA trunked mode operation half duplex means two-frequency simplex operation. 

Individual TETRA Subscriber Identity (ITSI): identity used to specify an individual TETRA user 
NOTE: An ITSI cannot be shared by multiple users. 

initial cell selection: act of choosing a first serving cell to register in 

NOTE: The initial cell selection is performed by procedures located in the MLE and in the MAC. When the cell 
selection is made and possible registration is performed, the MS is said to be attached to the cell. 

interrupted measurement: measurements performed by the lower layers interrupting current services 
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LLC frame: generic name given to one LLC data message, regardless the type of link (basic or advanced) used 

NOTE: An LLC frame comprises of a TL-SDU and LLC headers and a frame check sequence if applied. An LLC 
frame may be segmented for transmission. 

logical channel: generic term for any distinct data path 

NOTE: Logical channels are considered to operate between logical endpoints. 

MAC block: unit of information transferred between the upper MAC and lower MAC for a particular logical channel 

NOTE: Logical channels are e.g. SCH/F, SCH/HD or SCH/HU. The lower MAC performs channel coding for 
insertion into the appropriate physical slot, half slot or subslot. 

Main Control Channel (MCCH): principal common control channel transmitted by the infrastructure to control the 
MSs in a cell 

NOTE: The frequency of the main carrier for the cell is broadcast by the infrastructure, and the MCCH is located 
on timeslot 1 of the main carrier. 

Message Erasure Rate (MER): limit ratio of the messages detected as wrong by the receiver to all messages received 
in a given logical channel 

message trunking: traffic channel is permanently allocated for the complete duration of the call 

NOTE: The call may include several separate call transactions (several pressel activations by separate terminals). 
The channel is only de-allocated if the call is (explicitly) released or if a time-out expires. 

minimum mode: mode of operation in which the infrastructure allocates all four timeslots of the main carrier for traffic 
or assigned control purposes 

NOTE: In this mode, only frame 18 can be used for common control without disturbing the established services. 

monitoring: act of measuring the power of neighbour cells and calculate the path loss parameter C2 based upon 
information on neighbour cells broadcasted by the serving cell 

MS timing offset: delay of the received signal relative to the expected signal from an MS at zero distance under static 
channel conditions 

normal mode: mode of operation in which the MCCH is present in timeslot 1 of all frames 1 to 18 

on/off hook signalling: signalling procedure which includes an alerting process to the called user 

NOTE: An explicit response from the called user that he has answered is waited before the call can be set-up. 

piggy-backing: method of sending a layer 3 message concatenated with a layer 2 acknowledgement in the same air 
interface transmission 

Probability Of Undetected Erroneous Message (PUEM): limit ratio of the erroneous messages detected as right by 
the receiver to all messages received in a given logical channel 

protocol entity instance: instance of a protocol entity refers to one independent process related to the protocol defined 
by that entity 

NOTE: There may be multiple protocol entity instances e.g. circuit mode calls running simultaneously but 
independently from each other. 

QAM channel: channel on which signalling and data messages are sent using QAM bursts 

quarter symbol number: timing of quarter symbol duration 125/9 |is within a timeslot 

NOTE: In future releases of TETRA air interface standard the quarter symbol number may be valid only for 
features defined in the present document. 
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quasi transmission trunking: traffic channel is allocated for each call transaction (while the pressel is activated) and in 
addition the channel de-allocation is delayed for a short period at the end of the transaction (after the pressel release) 

NOTE: During this "channel hang-time" the channel allocation may be re-used for a new call transaction that is 
part of the same call. A delayed channel de-allocation procedure applies at the end of each transaction. 

random access attempt: period from the initiation of the random access procedure until the MS receives a response 
from the BS or abandons the procedure 

NOTE: The random access is abandoned e.g. after sending the maximum permitted number of retries. 

ranking: procedural method of listing cells in descending order from the most suitable for communication to the least 
suitable for communication 

NOTE: As inputs to the ranking procedure are: 

■ outputs from the monitor process (e.g. C2 parameters); 

■ outputs from the scanning process (e.g. CI parameters); 

■ network parameters received in the MLE broadcast. 

received SDU number: received SDU number N(R) is the number of the received data TL-SDU 

received segment sequence number: number of the currently received segment 

scanning: act of measuring the power of neighbour cells and calculate the path loss parameter CI based upon the 
information on the neighbour cells broadcasted by the neighbour cells themselves 

SDU number: number on the advanced link to keep TL-SDUs in order 

Secondary Control Channel (SCCH): control channel other than the MCCH 

NOTE: There are two types of SCCH: 

■ a common SCCH, which has the same functionality as the MCCH but is used only by a subset of 
the MS population; and 

■ an assigned SCCH, which may be allocated to certain MSs after an initial random access or paging 
message. 

segment: LLC segment is the advanced link unit of transmission and re-transmission 

NOTE: A segment is the numbered piece of a TL-SDU fitting into one MAC layer PDU (MAC block). 

sent SDU number (N(S)): the number of the current TL-SDU 

sent segment sequence number (S(S)): number of the currently sent segment 

serving cell: cell that is currently providing service to the MS 

simplex: half -duplex operation 

NOTE: Mainly used in TETRA standardization to differentiate half-duplex from (full) duplex communication. 

subscriber class: subdivision of the subscriber population 

NOTE: The operator may define the values and meaning of each class. 

surveillance: process of monitoring the quality of the radio link to the serving cell 

Time Division Multiple Access (TDMA) frame number: timing of TDMA frames within a multiframe 

timebase: device which determines the timing state of signals transmitted by a BS or MS 

timeslot number: timing of timeslots within a TDMA frame 

TLA: layer 2 SAP (TLA-SAP) 
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TLB: layer 2 SAP (TLB-SAP) 

TLC: layer 2 SAP (TLC-SAP) 

TLC-SAP: management Service Access Point (SAP) 

NOTE: The TLC-SAP is a way of modelling layer-to-layer communication for management and control piupose. 

TL-SDU: SDU from the service user (i.e. MLE) 

TM-SDU: SDU from the layer above MAC (i.e. LLC) 

transmission trunking: traffic channel is individually allocated for each call transaction (for each activation of the 
pressel) 

NOTE: The channel is immediately de-allocated at the end of the call transaction (subject to unavoidable protocol 
delays). 

U-plane: plane for user traffic signalling 

unacknowledged data transfer: service provided by the layer below which does not give any acknowledgement back 
to over the air interface from the lower layer peer entity 

unannounced cell reselection: cell reselection where the MS-MLE does not inform the old cell (leaving cell) that it 
intends to change to a new cell 

NOTE: Only the new cell (arriving cell) is informed about the cell reselection. 

unconfirmed service: service provided by the layer below which does not ensure response from peer entities before 
allowing new messages 

NOTE: This implies that messages to be transported may arrive in a different order at the peer entity since the 
sequence cannot be ensured. 

undeclared cell reselection: cell reselection where the MS-MLE does not inform the old cell (leaving cell) or the new 
cell (arriving cell) that cell change is performed 

useful part of a burst: modulation symbol times SNO to SNmax of a burst 

NOTE: The useful part of the burst is defined in clause 9. 

visited SwMI: SwMI which is broadcasting an MCC and/or MNC which is different than the MCC and MNC of the 
related TETRA identity 

NOTE: This definition is for the purposes of the air interface. In the inter system interface standard 

EN 300 392-3-5 [i.3] the visited SwMI is referring to the data base actions and not directly to the MCC or 
MNC of the MS and SwMI. 

n/4-DQPSK channel: channel on which signalling and data messages are sent using 7i/4-DQPSK bursts 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

7I/4-DQPSK 7t/4-shifted Differential Quaternary Phase Shift Keying 

71/8-D8PSK ji/8-shifted Differential 8 Phase Shift Keying 

AAA Authentication, Authorization, Accounting 

AACH Access Assignment CHannel 

ACCH Associated Control CHannel 

AACH-Q Access Assignment CHannel, QAM 

ACK first ACKnowledgement 

AGA Air - Ground - Air service 

AL Advanced Link 

ASSI Alias Short Subscriber Identity 

ATID Address Type Identifier in Demand 
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■ see clause 23.7.1.1 

■ see clause 23.7.1.2 

■ see clause 23.7.1.3 

■ see clause 23.7.1.4 

■ see clause 23.7.1.5 



ATSI Alias TETRA Subscriber Identity 

BBK Broadcast BlocK 

BCC Base station Colour Code 

BCCH Broadcast Control CHannel 

BCCH-Q Broadcast Control CHannel, QAM 

BER Bit Error Rate 

BKNl Broadcast blocK 1 

BKN2 Broadcast blocK 2 

BL Basic Link 

BLCH Base station Linearization CHannel 

BN Bit Number 

BNCH Broadcast Network CHannel 

BNCH-Q Broadcast Network CHannel, QAM 

BS Base Station 

BSCH Broadcast Synchronization CHannel 

BSD Berkeley Software Distribution 

BU Bad Urban 

C Conditional 

CI Path loss parameter ■ 

C2 Path loss parameter ■ 

C3 Path loss parameter ■ 

C4 Path loss parameter ■ 

C5 Path loss parameter ■ 

CB Control uplink Burst 

CC Call Control 

CCH Control CHannel 

CCH-Q Control CHannel, QAM 

CCK Common Cipher Key 

CHAP Challenge Handshake Authentication Protocol 

CLCH Common Linearization CHannel 

CLCH-Q Common Linearization CHannel, QAM 

CMCE Circuit Mode Control Entity 

CODEC Coder-decoder 

CONS Connection Orientated Network Service 

CoU Class of Usage 

CP Control Physical channel 

CPTI Calling Party Type Identifier 

CRC Cyclic Redundancy Check 

C-SAP Control Service Access Point 

CSS Carrier Specific Signalling 

CUB Control Uplink Burst 

DCK Dynamic Cipher Key 

DCOMP Data COMpression Protocol 

D-CT Downlink-Continuous Transmission 

D-CTT Downlink-Carrier Timesharing Transmission 

DHCPv6 Dynamic Host Configuration Protocol version 6 

DL DownLink 

DLL Data Link Layer 

D-MCCTT Downlink - Main Control Channel Timesharing Transmission 

DM0 Direct Mode Operation 

DNS Domain Name Server 

DSCP Differentiated Services Code Point 

DSS Downlink sync Sequence Set 

DTMF Dual Tone Multiple Frequency 

ECCH Extended Control CHannel 

EQ200 Equalizer Test 200 km/h 

ERP Effective Radiated Power 

FACCH Fast Associated Control CHannel 

FCB Frequency Correction downlink burst 

FCS Frame Check Sequence 

FDPS Full-slot Downlink Pilots Set 

FEC Forward Error Correction 
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FiSA Filler Set A 

FiSB Filler Set B 

FN Frame Number 

FrCS Frequency Correction Set 

FUPS Full-slot Uplink Pilots Set 

GIAT Group Identity Address Type 

GITI Group Identify Type Identifier 

GSSI Group Short Subscriber Identity 

GTSI Group TETRA Subscriber Identity 

HLR Home Location Register 

HT200 Hilly Terrain 200 km/h 

HUPS Half-slot Uplink Pilots Set 

ID IDentifier 

lEC International Electrotechnical Commission 

IETF Internet Engineering Task Force 

IMM IMMediate access parameter 

IP Internet Protocol 

IPCP Internet Protocol Control Protocol 

IPv4 IP version 4 

IPv6 IP version 6 

ISBN International Standard Book Number 

Roope53vISO International Organization for Standardization 

ISSI Individual Short Subscriber Identity 

ITSI Individual TETRA Subscriber Identity 

ITU International Telecommunications Union 

L2 Layer 2 

LA Location Area 

LAC Location Area Code 

LACC Location Area Country Code 

LANC Location Area Network Code 

LB Linearization Burst 

LCH Linearization CHannel 

LCH-Q Linearization CHannel, QAM 

LCMC-SAP Link entity Circuit Mode Control entity - Service Access Point 

LCP Link Control Protocol 

LDB Linearization Downlink Burst 

LIP Location Information Protocol 

LIP-SAP Location Information Protocol - Service Access Point 

LLC Logical Link Control 

LLME Lower Layer Management Entity 

LMM-SAP Link entity Mobility Management - Service Access Point 

LS Line Station 

LSB Least Significant Bit 

LTPD-SAP Link entity TETRA Packet Data - Service Access Point 

LZS Linearization downlink Zeroed Set 

M Mandatory 

M-bit More bit 

MAC Medium Access Control 

MCC Mobile Country Code 

MCCH Main Control CHannel 

MCM Minimum Control Mode 

MER Message Erasure Rate 

MEX Multimedia Exchange Layer 

MLE Mobile Link Entity 

MM Mobility Management 

MN Multiframe Number 

MNC Mobile Network Code 

MNI Mobile Network Identity 

MO Mobile station Originating 

mod modulo (base for counting) 

MPN Monitoring Pattern Number 

MS Mobile Station 
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MS-ISDN Mobile Station - ISDN number 

MST Multiple Slot Transmission 

MT Mobile station Termination 

MTO Mobile station Termination type 

MT2 Mobile station Termination type 2 

N(R) Received SDU (TL-SDU) Number 

N(S) Sent SDU (TL-SDU) Number 

NAP Net Assist Protocol 

NBNS Net BIOS Name Server 

NC Network Connection 

NCM Normal Control Mode 

NDB Normal Downlink Burst 

N-PDU Network layer protocol Protocol Data Unit 

NRA National Regulatory Administration 

NSAPI Network Service Access Point Identifier 

NUB Normal Uplink Burst 

O Optional 

0-bit Optional bit 

OTAR Over The Air Rekeying 

PA Power Amplifier 

PACQ Probability of synchronization burst ACQuisition 

PAP Password Authentication Protocol 

PC Protocol Control 

PCCC Parallel Concatenated Convolutional Code 

PCOMP Protocol COMpression Protocol 

PD Packet Data 

PDCH Packet Data CHannel 

PDF Probability Density Function 

PDP Packet Data Protocol 

PDS Power Density Spectrum 

PDU Protocol Data Unit 

PEI Peripheral Equipment Interface 

PL Physical Layer 

PMR Private Mobile Radio 

PPP Point-to-Point Protocol 

PSK Phase Shift Keying 

PUEM Probability of Undetected Erroneous Message 

QAM Quadrature Amplitude Modulation 

QoS Quality of Service 

RA Registered Area 

RAB Random Access uplink Burst 

RADIUS Remote Authentication Dial In User Service 

RCPC Rate Compatible Punctured Convolutional 

RDC Radio Downlink Counter 

RDC-NC Radio Downlink Counter - Non Conforming channel 

RDC-Q Radio Downlink Counter, QAM 

RF Radio Frequency 

RFC Request For Comments 

RM Reed-Muller 

RMS Root Mean Square 

RSC Recursive Systematic Code 

RTCM Radio Technical Commission for Maritime Services 

Rx Receive(r) 

S(R) Received segment Sequence number 

S(S) Sent segment Sequence number 

SACCH Slow Associated Control CHannel 

SAP Service Access Point 

SB Synchronization downlink Burst 

SCCH Secondary Control CHannel 

SCH SignalUng CHannel 

SCH/HD Signalling CHannel, Half size Downlink 

SCH-P8/HD SignalHng CHannel, n/8-D8PSK, Half size Downlink 
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SCH/HU 

SCH-P8/HU 

SCH/F 

SCH-P8/F 

SCH-Q 

SCH-Q/D 

SCH-Q/U 

SCH-Q/HU 

SCH-Q/RA 

SCK 

SCLNS 

SD 

SDS 

SDTI 

SDU 

SF 

SICH-Q 

SICH-Q/D 

SICH-Q/U 

SMI 

SMS 

SN 

SNA 

SNDCP 

SNEI 

SN-PDU 

SN-Q 

SN-SAP 

SS 

SSI 

SSN 

SSS 

SSVE 

STCH 

SwMI 

TCH 

TCH/7,2 

TCH/4,8 

TCH/2,4 

TCH-P8/10,8 

TCH/S 

TCP 

TDMA 

TE 

TE2 

TEI 

TEDS 

TL 

TLA-SAP 

TLB-SAP 

TLC-SAP 

TLE-SAP 

TM 

TMA-SAP 

TMB-SAP 

TMC-SAP 

TMD-SAP 

TMV-SAP 

TN 

TNCC-SAP 

TNMM 

TNMXPI-SAP 



Signalling CHannel, Half size Uplink 

Signalling CHannel, n/8-D8PSK, Half size Uplink 

Signalling CHannel, Full size 

Signalling CHannel, n/8-D8PSK, Full size 

Signalling CHannel, QAM 

Signalling CHannel, QAM Full size Downlink 

Signalling CHannel, QAM Full size Uplink 

Signalling CHannel, QAM Half size Uplink 

Signalling CHannel, QAM Random Access Uplink 

Static Cipher Key 

Specific ConnectionLess Network Service 

Sample Duration 

Short Data Service 

Short Date Type Identifier 

Service Data Unit 

Slot Flag 

Slot Information CHannel, QAM 

Slot Information CHannel, QAM Downlink 

Slot Information CHannel, QAM Uphnk 

Short Management Identity 

Short Message Service (in GSM) 

Symbol Number or SNDCP 

Short Number Address 

SubNetwork Dependent Convergence Protocol 

SNDCP Network Endpoint Identifier 

SNDCP - Protocol Data Unit 

Symbol Number in QAM 

SNDCP-Service Access Point 

Supplementary Service 

Short Subscriber Identity 

SubSlot Number 

Secondary sync Sequence Set 

Sum Square Vector Error 

STealing CHannel 

Switching and Management Infrastructure 

Traffic CHannel 

net rate = 7,2 kbit/s 

net rate = 4,8 kbit/s 

net rate = 2,4 kbit/s 

n/8-D8PSK, net rate : 



10,8 kbit/s 



Traffic CHannel, 

Traffic CHannel, 

Traffic CHannel, 

Traffic CHannel, 

Speech Traffic CHannel 

Transmission Control Protocol 

Time Division Multiple Access 

Terminal Equipment 

TE presenting a TETRA interface 

Terminal Equipment Identity 

TETRA Enhanced Data Service 

TETRA LLC 

TETRA LLC Service Access Point A 

TETRA LLC Service Access Point B 

TETRA LLC Service Access Point C 

TETRA LLC Service Access Point E 

TETRA MAC 

TETRA MAC Service Access Point A 

TETRA MAC Service Access Point B 

TETRA MAC Service Aaccess Point C 

TETRA MAC Service Aaccess Point D 

TETRA MAC Virtual SAP 

Timeslot Number 

TETRA Network layer Call Control - Service Access Point 

TETRA Network Mobility Management 

TETRA MEX layer PEI - Service Access Point 
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TNMXIT-SAP TETRA MEX layer internal application -Service Access Point 

TNSDS-SAP TETRA Network layer Short Data Service - Service Access Point 

TNSS-SAP TETRA Network layer Supplementary Services - Service Access Point 

TP Traffic Physical channel 

TPTI Transmitting Party Type Identifier 

TP-UD Transfer Protocol - User Data (in GSM) 

TS Time Sharing 

TSI TETRA Subscriber Identity 

TU50 Typical Urban 50 km/h 

Tx Transmit(ter) 

UCS-2 Universal Character Set coded in 2 octets 

UDH User Data Header 

UDP User Datagram Protocol 

UL UpLink 

U-MST UpHnk Multiple Slot Transmission 

UMTS Universal Mobile Telecommunications System 

U-SAP User Service Access Point 

UP Unallocated Physical channel 

USS Uplink sync Sequence Set 

USSI Unexchanged Short Subscriber Identity 

UTF-16BE Unicode Transformation Format serialized as two bytes in Big-Endian format 

V+D Voice plus Data 

(V)ASSI Visited Alias Short Subscriber Identity 

(V)GSSI Visited Group Short Subscriber Identity 

WAP Wireless Application Protocol 
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4.1 



Radio aspects 



Introduction 



This clause is an introduction to the radio aspects of the TETRA V+D standard. It consists of a general description of 
the organization of the radio-related functions with reference to the clauses where each part is specified in details. 
Furthermore, it introduces the reference configuration that will be used throughout the present document. 



4.2 Set of logical channels 



The radio subsystem provides a certain number of logical channels as defined in clause 9. The logical channels 
represent the interface between the protocol and the radio. 



4.3 Reference configuration 



For the purpose of elaborating the specification of the radio-related functions, a reference configuration of the 
transmission chain is used as shown in figures 4. 1 and 4.2. 

NOTE: Only the transmission part is specified, the receiver being specified via overall performance requirements. 

With reference to this configuration, the radio clauses address the following functional units: 

• clause 5: bit-to-symbol mapping encoding and modulation; 

• clause 6: characteristics of transmitter and receiver; 

• clause 8: channel coding, interleaving and scrambling; 

• clause 9: burst building and logical channel multiplexing. 

This reference configuration also defines a number of points of vocabulary in relation to the names of bits at different 
levels in the configuration. 
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Figure 4.1 : Reference configuration for phase modulation 
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Figure 4.2: Reference configuration for QAIV! modulation 



4.4 



Error control schemes 



The different error control schemes are described in detail in clause 8. 

4.5 Multiple access and time slot structure 
4.5.1 General 

The access scheme is TDMA with 4 physical channels per carrier. For phase modulation the carrier bandwidth is 
25 kHz. For QAM the carrier bandwidth is 25 kHz, 50 kHz, 100 kHz or 150 kHz. 

The following clauses briefly introduce the structures of hyperframe, multiframe, frame, timeslot, and burst, as well as 
the mapping of the logical channels onto the physical channels. The appropriate specifications are found in clause 9. 
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4.5.2 Hyperframes, multiframes and frames 

A diagrammatic representation of the TDMA structure is shown in figure 4.3. 
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Figure 4.3: V+D TDMA structure 

The hyperframe level defines the top-level frame hierarchy. One hyperframe is subdivided into 60 multiframes, and 

lasts 61,2 s. 

One multiframe is subdivided in 18 frames, and has a duration of 1,02 s. The eighteenth frame in a multiframe is a 
control frame. 

One frame is subdivided into 4 time slots, and has duration of 170/3 ms ~ 56,67 ms. 

4.5.3 Time slots and bursts 

The time slot is a time interval of 85/6 ms ~ 14,167 ms. For phase modulation the time slot corresponds to 255 symbol 
durations, each one with a duration of 500/9 [is = 55,56 |as. For QAM the time slot is divided into 34 modulation 
symbol durations, each one with a duration of 5/12 ms ~ 416,7 |is. The up-link timeslots may be subdivided into 
2 subslots. 

The physical content of a time slot is carried by a burst. The different types of bursts are defined in clause 9. 
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4.5.4 Mapping of logical channels onto physical channels 

Three types of physical channels are defined: 

• the Traffic Physical channel (TP) carrying mainly traffic channels; 

• the Control Physical channel (CP) carrying exclusively the control channel. One CP channel is defined as the 
MCCH, the others are called Extended Control Channel (ECCH). The Radio Frequency (RF) carrier 
containing the MCCH is called the main carrier; and 

• the UP channel is a physical channel not allocated to one or more MS. 

The mapping of the logical channels onto the physical channels, according to the mode of operation, is defined in 
clause 9. 

4.6 Coding, interleaving and scrambling 

The coding, interleaving and scrambling schemes associated with each logical channel shall be as specified in clause 8. 

4.7 IVIodulation 

For phase modulation the modulation scheme is 7t/4-shifted Differential Quaternary Phase Shift Keying (7t/4-DQPSK) 
or 7t/8-shifted Differential 8 PSK (jt/8-D8PSK). The modulation rate is 36 kbit/s for 7t/4-DQPSK and 54 kbit/s for 
Jt/8-D8PSK. 

For QAM the modulation scheme is 4-QAM, 16-QAM or 64-QAM. A multi sub-carrier approach with 8 sub-carriers 
per 25 kHz is used, i.e. 8, 16, 32 and 48 sub-carriers in 25 kHz, 50 kHz, 100 kHz and 150 kHz carriers respectively. The 
modulation symbol rate on each sub-carrier is 2400 symbols/s. 

These schemes are specified in detail in clause 5. 

4.8 Transmission and reception 

The modulated stream is transmitted on a RF carrier. 

The specific RF channels, together with the requirements on the transmitter and the receiver characteristics are specified 
in clause 6. 

For Base Stations (BSs) and MSs, power classes are defined in clause 6. 

4.9 Other radio-related functions 

Transmission involves other functions. These functions, which may necessitate the handling of specific protocols 
between BS and MS, are the radio subsystem synchronization, the radio subsystem adaptive power control and for 
D8PSK and QAM channels, the radio subsystem adaptive link control. 

The synchronization: 

• incorporates frequency and time acquisition by the receiver; 

• incorporates adjustment of the timebase of the MSs; 

• the requirements on synchronization are specified in clause 7. 
The adaptive power control: 

• adjusts the RF transmit power, in order to ensure that the required quality of transmission is achieved with the 
least possible radiated power; 

• this function is managed by the MS during the initial access, and by the MS or BS during operational use; 
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• this function is provided for battery saving and reduction of interference levels; 

• the requirements on adaptive power control are specified in clause 10. 
The adaptive link control: 

• adjusts the modulation and coding to achieve the required Quality of Service; 

• the measurements required for adaptive link control are specified in clause 10. 



4.10 Performance 



Under typical urban fading conditions (i.e. multipath delays no greater than 5 |is), the quality thresholds for speech 
using the full-rate ACELP Codec (EN 300 395-2 [21]) with 7t/4-DQPSK modulation are reached at a C/I^ (co-channel 

interference) value of 19 dB, and a dynamic reference sensitivity level of -106 dBm for BSs and -103 dBm for mobile 
equipment. 

Details of performance requirements of phase modulation and QAM modulation in various channel conditions are given 
in clause 6. 



4.11 TETRA modes of operation 



The TETRA modes of operation which are supported by the present document and which impact on the radio 
descriptions are: 

• Transmission modes: 

Downlink-Continuous Transmission (D-CT) mode: 

■ the D-CT mode is mandatory for MSs, i.e. such equipment shall be able to interwork with a 
TETRA BS that would be in the D-CT mode. 

Downlink-Carrier Timesharing Transmission (D-CTT) mode. 

Downlink-Main Control Channel Timesharing Transmission (D-MCCTT) mode. 

Multiple Slot Transmission (MST) mode. 

• Control modes: 

Normal Control Mode (NCM): 

■ the NC mode is mandatory for all TETRA equipment. 
Minimum Control Mode (MCM): 

■ the MC mode is mandatory only for the MSs. 

In the following clauses, each of the above modes of operations are defined. 

4.1 1 .1 Transmission modes 

4.11.1.1 D-CT mode 

In the D-CT mode, the BS always uses the continuous downlink bursts. The transmission is continuous on the main 
carrier. On the other carriers discontinuous transmission is allowed but is transparent for the MSs. 

4.11.1.2 D-CTT mode 

In the D-CTT mode, a carrier frequency may be shared by several cells, each of its four physical channels being 
allocated independently to these cells. The BS uses the discontinuous downlink bursts. 
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4.11.1.3 D-MCCTTmode 



In the D-MCCTT mode, the MCCH is shared by several cells, each of its frames being allocated independently to these 
cells. The BS uses the discontinuous downlink burst. 

4.11.1.4 U-MST mode 

In the MST mode, two to four physical channels are used for the same communication. This is used, for example, to 
increase the data transmission rate or to mix voice and data. 

4.11.2 Control modes 

4.1 1 .2.1 Normal Control Mode 

The Normal Control Mode (NCM) provides the TETRA services with full performance. It requires the assignment of 
one MCCH. 

4.1 1 .2.2 Minimum Control Mode 

The Minimum Control Mode (MCM) provides the TETRA services with reduced performance. In the MCM, all 
physical channels of each RF carrier should be devoted to traffic. 
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5.1 



Modulation 



Introduction 



The clauses 5.2 to 5.7 apply to the baseband part of the transmitter in the case of phase modulation channels, and 
clauses 5.8 to 5.18 apply to the baseband part of the transmitter in the case of QAM channels. 



5.2 Modulation type 



The modulation used shall be 7t/4-shifted Differential Quaternary Phase Shift Keying (7t/4-DQPSK) or 7t/8-shifted 
Differential 8 PSK (7t/8-D8PSK). 



5.3 



Modulation rate 



The modulation rate shall be 36 kbit/s for 7t/4-DQPSK and 54 kbit/s for 7t/8-D8PSK. 

5.4 Modulation symbol definition 

B(m) denotes the modulation bit of a sequence to be transmitted, where m is the bit number. The sequence of 
modulation bits shall be mapped onto a sequence of modulation symbols S(k), where k is the corresponding symbol 
number. 

The modulation symbol S(k) shall result from a differential encoding. This means that S(k) shall be obtained by 
applying a phase transition D^k) to the previous modulation symbol S(k-l), hence, in complex notation: 

S{k) = S{k - 1) exp{jD^k)) 

^(^) = ' (5.1) 

The above expression for S(k) corresponds to the continuous transmission of modulation symbols carried by an arbitrary 
number of bursts. The symbol S(0) is the symbol before the first symbol of the first burst and shall be transmitted as a 
phase reference. 

In the case of 7t/4-DQPSK modulation, the phase transition D(^k) shall be related to the modulation bits as shown in 
table 5.1 and figure 5.1. 

Table 5.1 : Phase transitions for 7i/4-DQPSK modulation 



B(2k-1) 


B(2k) 
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Figure 5.1 : 7i/4-DQPSK modulation symbol constellation and possible transitions 

The complex modulation symbol S(k) shall take one of the eight values exp(j n7!/4), where n = 2, 4, 6, 8 for even k and 
n = 1, 3, 5, 7 for odd k. The constellation of the modulation symbols and the possible transitions between them are as 
shown in figure 5.1. 

In the case of 71/8-D8PSK modulation, the phase transition D(j)(k) shall be related to the modulation bits as shown in 
table 5.2 and figure 5.2. 

Table 5.2: Phase transitions for 71/8-D8PSK modulation 
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Figure 5.2: 71/8-D8PSK modulation symbol constellation and possible transitions 
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The complex modulation symbol S(k) shall take one of the sixteen values exp(j n7!/8), where n = 2, 4, 6 to 16 for even k 
and 1, 3, 5 to 15 for odd k. The constellation of the modulation symbols and the possible transitions between them are as 
shown in figure 5.2. 

5.5 Modulated signal definition 

The modulated signal, at carrier frequency Z^, shall be given by: 

M{t) = Re{s{t) exp[j[27tf,t + ^o))} 

Where: 

• (Z)q is an arbitrary phase; 

• s(t) is the complex envelope of the modulated signal defined as: 

s{t)= I S{k)g{t-t,) 

1^=0 (5.3) 

Where: 

• Kis, the maximum number of symbols; 

• r is the symbol duration; 

• tj^ = kT is the symbol time corresponding to modulation symbol S(k); 

• g(t) is the ideal symbol waveform, obtained by the inverse Fourier transform of a square root raised cosine 
spectrum G(f), defined as follows: 

Gif) = 1 fo, \f\^{1-^)/2T 

G{f) = ^0.5{l-sin(7,{^f\T-l)/2a)) ^^^ [1 - a)/2T <\f\<{1 + a)/2T 

G{f) = ^ \f\>{1 + a)/2T ,^ ,, 

^ ' for M V // (5 4-) 

Where oris the roll-off factor, which determines the width of the transmission band at a given symbol rate. The value of 
a shall be 0,35. For practical implementation, a time limited windowed version of g(t), designed under the constraints 
given by the specified modulation accuracy and adjacent channel attenuation may be applied. 

5.6 IVIodulation filter definition 

The ideal modulation filter shall be a linear phase filter which is defined by the magnitude of its frequency response 

\H(f)\ = G(f). 
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5.7 



Modulation block diagram 



A block diagram of the modulation process is shown on figure 5.3. This diagram is for explanatory purposes and does 
not prescribe a specific implementation. The modulation filter excited by the complex Dirac impulse function 
S(k)h(t-t]^) ideally has an impulse response g(t). 
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Figure 5.3: Block diagram of the modulation process 



5.8 Introduction to QAM channels 

Given the discrete channelization ranging from single 25 kHz carriers up to 150 kHz, there is insufficient bandwidth to 
permit resolution of individual multi-path echoes in the transmission path. It is thus necessary to ensure that the channel 
time delay is a small fraction of the symbol period for negligible channel induced Inter Symbol Interference. For this 
reason, each QAM carrier is divided into a number of frequency-division multiplexed sub-carriers, each carrying a 
complex signal using the QAM modulation. The sub-carrier approach is used because the low symbol rate in each 
sub-carrier gives the modulation inherent resistance to time dispersion hence avoiding the need for an adaptive 
equalizer. 

Clauses 5.9 to 5.18 apply to the baseband part of the transmitter. 

5.9 Modulation type 

The modulation types used on each sub-carrier shall be 4-QAM, 16-QAM or 64-QAM. 

5.1 Use of sub-carriers in QAM carriers 

A multi sub-carrier approach with 8 sub-carriers per 25 kHz is used, i.e. 8, 16, 32 and 48 sub-carriers in 25 kHz, 
50 kHz, 100 kHz and 150 kHz carriers respectively. 

5.11 Modulation rate 

The modulation symbol rate on each sub-carrier shall be 2 400 symbols/s. The overall carrier symbol rate shall be 
19 200 symbol/s for 25 kHz carriers, 38 400 symbol/s for 50 kHz carriers, 76 800 symbol/s for 100 kHz carriers and 
1 15 200 symbol/s for 150 kHz carriers. The modulation gross bit rates are given in table 5.3. 

Table 5.3: Gross bit rates for QAM Carriers (kbit/s) 



Modulation type 


Carrier bandwidth 


25 kHz 


50 kHz 


100 kHz 


150 kHz 


4-QAM 


38,4 


76,8 


153,6 


230,4 


16-QAM 


76,8 


153,6 


307,2 


460,8 


64-QAM 


115,2 


230,4 


460,8 


691,2 
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5.12 Modulation symbol definition 



In this clause the term symbol refers to the composite signal, which is emitted from the modulator at a 2 400 symbol/s 
rate. Each sub-carrier symbol may carry data, time domain pilots, or time domain synchronization information. The 
term sub-carrier symbol refers to a generic symbol in a particular sub-carrier. Each data sub-carrier symbol conveys 
a predetermined number of bits of information dependent on the symbol constellation complexity. The synchronization 
sub-carrier symbols and pilot sub-carrier symbols convey no data information. 



5.13 Bit to symbol mapping 



Figures 5.4, 5.5 and 5.6 show the three different mappings of QAM symbols onto a complex plane. It can be seen from 
the three constellation diagrams that the pilot sub-carrier symbols and synchronization sub-carrier symbols are not 
constrained to lie on the constellation points, instead, they can take on any phase angle as long as the magnitude of these 
symbols corresponds to the synchronization/pilot locus. A circle of unity amplitude is selected as this locus independent 
of the modulation. Note that this circle is not the outer circle of 16-QAM and 64-QAM constellations. The header sub- 
carrier symbols also lie on this circle but use 4-QAM in all three cases. 

Tables 5.4, 5.5 and 5.6 show the vector and bit definition for 4-QAM, 16-QAM and 64-QAM respectively. 

The modulation symbol Sni(k) shall be related to the modulation bits defined in tables 5.4, 5.5 and 5.6, subject to the 
appropriate scaling factors: 

• for 4-QAM the values in table 5.4 shall be multipHed by 1/V2. 

• for 16-QAM the values in table 5.5 shall be multipHed by 1/VlO. 

• for 64-QAM the values in table 5.6 shall be multiplied by 1/V42. 
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Figure 5.4: 4-QAM Symbol Constellation 
Table 5.4: Vector and bit definition (4-QAM) 
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Figure 5.5: 16-QAM Symbol Constellation 



Table 5.5: Vector and bit definition (16-QAM) 
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Figure 5.6: 64-QAM Symbol Constellation 



Table 5.6: Vector and bit definition (64-QAM) 
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5.14 Data, synchronization and pilot symbol multiplexing 

Figure 5.7 shows the muhiplexing of data, synchronization and pilot symbols. 



k=2 -> 4-QAM 
k=4-> 16-QAM 
k=6 -> 64-QAM 
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Figure 5.7: Symbol multiplexing 
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5.1 5 Sub-carrier frequency domain multiplexing 

The number of sub-carriers M shall be 8, 16, 32 and 48 respectively for 25 kHz, 50 kHz, 100 kHz and 150 kHz carrier 
bandwidths. The sub-carrier centre frequency /^^^ in Hz shall be defined by the following formula: 

fm= (0,5625 - (M/2-m) x 1,125)/T (5.5) 

form = a 1,....,M-1 
where Tis the symbol duration in s as defined in clause 5.11. This leads to a sub-carrier spacing of 2,7 kHz. 

5.16 IVIodulated signal definition 

The modulated signal, at carrier frequency /c, shall be given by: 

M{t) = Re{s{t) exp[j[27tf,t + ^o))} 

Where: 

• ^Q is an arbitrary phase; 

• s(t) is the complex envelope of the modulated signal defined as: 



(5.6) 



N 



s„Xt) = Y,SJn)g(t-tJe^''>''"''^'"' (5.7) 

«=i 

M-l M-l N 

m-O m-0 «-l 

Where: 

M is the number of sub-carriers; 

A^ is the number of modulated symbols on each sub-carrier in one slot; 

T is the symbol duration on each sub-carrier; 

f,^ = riTis the symbol time corresponding to modulation symbol SJn); 

SiJn) is the modulation symbol at time t„ on sub-carrier m; 

CO^ = 27tf^ is sub-carrier angular frequency; 

(p ,„ is the phase control for sub-carrier m during the slot; 

g(t) is the ideal symbol waveform, obtained by the inverse Fourier transform of a square root raised cosine 
spectrum G(f), defined as follows: 



G(f)= ^0.5(1 -sin(7,{2\f\T-l)/2a)) ^^^ [1 -a)/2T <\f\<{l + a)/2T 

G{f) = f^^ \f\^{l^a)/2T ^33^ 

Where oris the roll-off factor, which determines the width of the transmission band at a given symbol rate. The value of 
a shall be 0,20. For practical implementation, a time limited windowed version of g(t), designed under the constraints 
given by the specified modulation accuracy and adjacent channel attenuation may be applied. 
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5.1 7 Modulation filter definition 

The ideal modulation filter shall be a linear phase filter which is defined by the magnitude of its frequency response 

\H(f)\ = G(f). 

The frequency domain specification G(f) of the transmit pulse-shape filter results in a unique specification for the time 
domain impulse response g(t). Figure 5.8 shows a sample implementation of the impulse response. Time f^in 
Figure 5.8, the peak of the impulse response for the first modulated symbol in a slot is an important parameter in the 
multi sub-carrier modulation specification. 




Figure 5.8: Sample impulse response 

The phase relationship of the sub-carriers to the synchronization sub-carrier symbols and the pilot sub-carrier symbols 
is important in multi sub-carrier modulation. For the synchronization sub-carrier symbols to produce a correct time 
synchronization pattern, the phase relationship of the synchronization sub-carrier symbols to the instantaneous 
sub-carrier frequency domain multiplexers in equation 5.7 must be controlled. Also, by exercising control over the 
phase relationship of the sub-carrier frequency domain multiplexers to the pilot sub-carrier symbols, the pilots may be 
designed to achieve lowest peak-to-average power ratio for the composite multi sub-carrier modulation. Time tg in 
figure 5.8 defines the time reference at the start of modulation when all sub-carrier frequency domain multiplexers shall 
have a value of radians, i.e, co^^^ tQ+ ^^ = 0, which is equivalent to say that the sub-carrier frequency domain 
multiplexers all have a phase of radians at f = tg. 

The condition (O^ tg + cp^ = needs to be fulfilled for every transmitted slot. This mathematical expression is correct if 



the notation in equation 5.7, i.e. /^ , refers to a single slot. 



NOTE: This condition can be fulfilled by pre-rotating all sub-carrier symbols of each transmitted slot n by 

-COjJt H- n X N X T) radians, where N x T is the slot duration and n is an integer equal or greater than 0. 
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5.18 Modulation block diagram 



A block diagram of the modulation process is shown on figure 5.9. This diagram is for explanatory purposes and does 
not prescribe a specific implementation. 
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Figure 5.9: Block diagram of the modulation process 
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Radio transmission and reception 



6.1 Introduction 

Clause 6 defines the requirements for the MS and the BS transceiver of the TETRA 7t/4-DQPSK, D8PSK and QAM 
systems. Clause 6 is applicable to TETRA systems operating at radio frequencies of 300 MHz to 1 GHz. 

NOTE: The values specified in clause 6 are based on calculations, simulations, or existing standards. It is, 

therefore, essential that these values are confirmed during the validation phase. The values for the carrier 
number are defined in clause 21. 

6.2 Frequency bands and channel arrangement 

When used in dedicated TETRA frequency bands, TETRA MSs shall transmit in the TETRA uplink frequency band, 
and TETRA BSs shall transmit in the TETRA downlink frequency band. The uplink and downlink frequency bands are 
of equal width. Their edges shall be as follows: 

• F ^1^ to Fiip^ ffiax (MHz): mobile transmit, base receive; 

• Fdw, min to F^i^^ f,^x (MHz): base transmit, mobile receive. 

The TETRA 7t/4-DQPSK and D8PSK RF carrier separation shall be 25 kHz. For QAM the RF carrier separation shall 
be 25 kHz, 50 kHz, 100 kHz and 150 kHz. In order to ensure compliance with the radio regulations outside the band, a 
guard band may be needed at each side of both uplink and downlink bands. 

The centre frequencies of downlink RF carriers, F^^^fi^ shall be given by the value of downlink carrier frequency 
defined in clause 21, the corresponding centre frequency of uplink RF carriers, Fupg., shall be given by: 

up,c ~ down,c ' V'J-^) 

When a TETRA system is operated in frequency bands used for analogue Private Mobile Radio (PMR), the uplink and 
downlink transmit and receive centre frequencies and the duplex spacing (D) will be allocated by the National 
Regulatory Administration (NRA). 

In all frequency bands, the TETRA stations shall use a fixed duplex spacing D. 



6.3 Reference test planes 



For the purposes of testing, all TETRA stations shall have at least one antenna connector as specified by the 
manufacturer. 

The base station equipment may include, at the discretion of the manufacturer, some or all of the optional items shown 
in figure 6.1 if they are necessary to meet the requirements of the present document, with the antenna connection(s) at 
Points IT, IR or 2. The equipment must comply with the present document at the antenna connector(s) specified. 

In the case of equipment comprising several transmitters, only one transmitter shall be transmitting during all 
measurements, except for measuring intermodulation attenuation. 
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Figure 6.1 : Reference interconnection of transmitters and receivers at BS 



6.4 



Transmitter characteristics 



6.4.1 Output power for phase modulation 

In clauses 6.4.1.1 and 6.4.1.2, power is defined as the average power, measured through the square root raised cosine 
filter defined in clause 5 over the useful part of the burst as defined in clause 9. 

The powers at which MSs or BSs may operate are specified in clauses 6.4.1.1 and 6.4.1.2. 

6.4.1.1 Base Station (BS) 

The BS transmitter nominal power shall be as defined in table 6.1 according to its power class. 

Table 6.1 : Nominal power of BS transmitters 



Power class 


Nominal power per carrier 


1 (40 W) 


46dBm 


2 (25 W) 


44dBm 


3(15W) 


42dBm 


4(10W) 


40dBm 


5(6,3W) 


38dBm 


6(4W) 


36dBm 


7(2,5W) 


34dBm 


8(1,6W) 


32dBm 


9(1 W) 


30dBm 


10 (0,6 W) 


28dBm 



NOTE: The tolerances of the nominal power per carrier are given in EN 300 394- 1 . 
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6.4.1.2 Mobile Station (MS) 

The MS nominal power shall be as defined in table 6.2 according to its power class. 

Table 6.2: Nominal power of MS transmitters 



Power class 


Nominal power 


1 (30 W) 


45dBm 


1L( 17,5 W) 


42,5 dBm 


2(10W) 


40dBm 


2L(5,6W) 


37,5 dBm 


3(3W) 


35 dBm 


3L(1,8W) 


32,5 dBm 


4(1 W) 


30 dBm 


4L(0,56W) 


27,5 dBm 



NOTE 1 : The tolerances of the nominal power per carrier are given in EN 300 394- 1 . 

The different power levels needed for adaptive power control (see clause 10) shall have the values as defined in 
table 6.3, starting from the minimum power control level of 15 dBm (step level 7) up to the nominal power level 
corresponding to the class of the particular MS as stated in table 6.2. 

Table 6.3: Nominal MS power control levels 



Step level 


Power 


1 


45 dBm 


2 


40 dBm 


3 


35 dBm 


4 


30 dBm 


5 


25 dBm 


6 


20 dBm 


7 


15 dBm 



NOTE 2: The tolerances of the nominal power per carrier are given in EN 300 394-1 [i.l3]. 

6.4.2 Unwanted conducted emissions for phase modulation 



6.4.2.1 



Definitions 



Unwanted emissions are defined as conducted emissions at frequencies or time intervals outside the allocated channel. 
The specified limits shall be met under realistic conditions, for instance under varying antenna mismatch. Unless 
otherwise stated, unwanted emissions are specified for an equipment in the active transmit (act Tx) state, i.e. whenever 
this equipment transmits bursts, or whenever it ramps-up/linearizes or ramps-down. The non-active transmit (nonact 
Tx) state is a state occurring during two timeslot durations (approximately 28 ms) before and after any active transmit 
state. 

Tx level 



(Lmin) - 



non-Tx 


nonact Tx 


act Tx 


nonact Tx 




1 1 




2 slots 


2 slots 


non-Tx 







time 



Figure 6.2: Schematic presentation of transmitter states 
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An equipment is said to be in the non-transmit (non-Tx) state whenever it is not in the active or non-active transmit state 
(refer to figure 6.2). 



6.4.2.2 



Unwanted emissions close to the carrier 



The emissions in clauses 6.4.2.2.1 and 6.4.2.2.2 shall be measured through the square root raised cosine filter with a 
roll-off factor of 0,35 and a symbol duration of 500/9 jis, as defined in clauses 5.5 and 5.6. 

Measurements shall be done at the nominal centre frequency and at the frequency offsets specified in tables 6.4 and 6.5. 
When applicable, relative measurements (dBc) shall refer to the level measured at the nominal centre frequency. 



6.4.2.2.1 



Emission during the useful part of the burst 



The levels given in tables 6.4 and 6.5 shall not be exceeded at the listed frequency offsets from the nominal carrier 
frequency. 

Table 6.4: Maximum adjacent power levels for frequencies below 700 MHz 



Frequency offset 


Maximum level for 

MS power classes 

4 and 4L 


Maximum level for 
other power classes 


25 kHz 


-55 dBc 


-60 dBc 


50 kHz 


-70 dBc 


-70 dBc 


75 kHz 


-70 dBc 


-70 dBc 



In any case, no requirement less than -36 dBm shall apply i.e. the maximum power level need not be less than -36 dBm. 
Table 6.5: Maximum adjacent power levels for frequencies above 700 MHz 



Frequency offset 


Maximum level 


25 kHz 


-55 dBc 


50 kHz 


-65 dBc 


75 kHz 


-65 dBc (see note) 


NOTE: A level of -70 dBc shall apply for: 

BS Power Classes 1 , 2 and 3 and for 
MS Power Classes 1 and 1L. 



In any case, no requirement less than -36 dBm shall apply i.e. the maximum power level need not be less than -36 dBm. 

The specifications assume that the centre frequency is at the above listed frequency offsets from the nominal carrier 
frequency. The measured values shall be averaged over the useful part of the burst (see clause 9). The scrambled bits 
shall have a pseudo-random distribution from burst to burst. 



6.4.2.2.2 



Emission during the switching transients 



At the frequency offset from the nominal carrier frequency given below, peak power measurements shall be done, 
covering at least the ramp-up period and the ramp-down period (figure 6.3, periods f; and t^) (see clause 6.4.5 for 
definition of tj and tj). 

The maximum hold level of -45 dBc for MS Power Classes 4 and 4L and -50 dBc for other Power Classes at 
a frequency offset of 25 kHz shall not be exceeded. This requirement does not apply to linearization channels. 

In any case no requirement less than -36 dBm shall apply i.e. the maximum peak power level need not be less than 
-36 dBm. 
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6.4.2.3 



Unwanted emissions far from the carrier 



These unwanted emissions are emissions (discrete, wideband noise, modulated or un-modulated) occurring at offsets of 
equal to, or greater than, 100 kHz from the carrier frequency, measured in the frequency range 9 kHz to 4 GHz. 

a) Discrete spurious: 

the maximum allowed power for each spurious emission shall be less than -36 dBm measured in 
100 kHz bandwidth in the frequency range 9 kHz to 1 GHz and -30 dBm measured in 1 MHz bandwidth 
in the frequency range 1 GHz to 4 GHz (1 GHz to 12,75 GHz for equipment capable of operating at 
frequencies above 470 MHz). Specific measurement method are required both when measuring within 
-frb of carrier frequency, due to the presence of wideband noise, and in the lower part of the spectrum. 

b) Wideband noise: 

the wideband noise levels, measured through the modulation filter defined in clause 5.6 should not 
exceed the limits shown in tables 6.6 and 6.7, for the nominal power levels as stated, and at the listed 
offsets from the nominal carrier frequency. The requirements apply symmetrically to both sides of the 
transmitter band. 

Table 6.6: Wideband noise limits for frequencies below 700 MHz 



Frequency offset 


Maximum wideband noise level 


MS nominal power 
level < 1 W (class 4) 


MS nominal power 

level = 1,8 W or 3 W 

(class 3L or 3) 


MS nominal power level 

> 5,6 W (class 2L) 

BS all classes 


100 kHz to 250 kHz 


-75 dBc 


-78 dBc 


-80 dBc 


250 kHz to 500 kHz 


-80 dBc 


-83 dBc 


-85 dBc 


500 kHz to frb 


-80 dBc 


-85 dBc 


-90 dBc 


>frb 


-100 dBc 


-100 dBc 


-100 dBc 


NOTE: frb denotes the frequency offset corresponding to the near edge of the receive band or 5 IVIHz 
(10 IVIHz for frequencies above 520 IVIHz) whichever is greater. 



Table 6.7: Wideband noise limits for frequencies above 700 MHz 



Frequency offset 


Maximum wideband noise level 


MS nominal power level 
< 1 W (class 4) 


MS nominal power levels 

from 1,8 W to 10 Wand 

BS Nominal power levels 

<10W 


MS and BS nominal power 
levels from 15 W to 40 W 


100 kHz to 250 kHz 


-74 dBc 


-74 dBc 


-80 dBc 


250 kHz to 500 kHz 


-80 dBc 


-80 dBc 


-85 dBc 


500 kHz to frb 


-80 dBc 


-85 dBc 


-90 dBc 


>frb 


-100 dBc 


-100 dBc 


-100 dBc 


NOTE: frb denotes the frequency offset corresponding to the near edge of the received band or 1 IVIHz 
whichever is greater. 



All levels in tables 6.6 and 6.7 are expressed in dBc relative to the actual transmitted power level, and in any case no 
limit tighter than -55 dBm for offsets </,■), or -70 dBm for offsets >frh shall apply. 



6.4.2.4 



Unwanted emissions during the CLCH and BLCH 



The following emissions shall be measured through a square root raised cosine filter with a roll-off factor of 0,35 and a 
symbol duration of 500/9 jis as defined in clauses 5.5 and 5.6. 

The sum of the time periods during which the peak power, at a frequency offset of +25 kHz during the BLCH/CLCH, is 
above -45 dBc shall not exceed 1 ms. This peak power shall never exceed -30 dBc. 

NOTE: dBc refers to the transmit power during normal operation after the CLCH or BLCH. 
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6.4.2.5 Unwanted emissions in the non-transmit state 

The specifications of clause 6.5.4.2 apply. 

6.4.3 Unwanted radiated emissions for phase modulation 

Unwanted radiated emissions are emissions (whether modulated or un-modulated) radiated by the cabinet and structure 
of the equipment (MS or BS). This is also known as cabinet radiation. 

The limits given in clause 6.4.2.3 shall apply for frequencies between 30 MHz and 4 GHz only. 

6.4.4 RF tolerance for phase modulation 

The RF tolerance for BSs and MSs is defined in clause 7. 



6.4.5 RF Output power time mask for phase modulation 

The transmit level versus time mask for TETRA station transmission is shown in figure 6.3. For the time mask the 
power level of dBc refers to the output power level of the TETRA station under consideration. 

Tx level 
(dBc) 

+ 6 



+ 3 




mm 



r 



////: 



-I 



^ 




■1.2 

Symbol time of SA/0 symbol time of SNmax 

Figure 6.3: Transmit level versus time mask 



Table 6.8: Transmit level versus time mask symbol durations (refer figure 6.3) 



Burst Type 


tl 


t2 


t3 


Control uplink 


16 


103 


15 


Linearization uplink 


119 





15 


Linearization downlink 


107 








Normal uplink 


16 


231 (see note) 


15 


Discontinuous downlink 


7 


246 (see note) 


7 


Continuous downlink 


Unspecified 


Unspecified 


Unspecified 


NOTE: In the case of single slot transmission. 
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Whenever bursts are consecutively transmitted by the same TETRA station on the same frequency, the transmit level 
versus time mask applies at the beginning of the transmission of the first burst and at the end of the transmission of the 
last burst. 

The symbol numbers referred to as SNO and SNmax are defined in clause 9. The timing of the transmitted bursts is 
specified in clause 7. The time periods f;, t2 and fj, whose durations are stated in table 6.8, are defined in the following 
way: 

• the time f; starts at the beginning of the ramp-up of the first burst, and expires just before the symbol time of 
SNO; 

• the time t2 starts at the symbol time of SNO of the first burst and finishes at the symbol time of SNmax of the 
last burst; 

• the time f j starts just after the symbol time of SNmax of the last burst and finishes at the end of the ramp-down. 

In this clause, the specifications of clauses 6.4. 1 and 6.6. 1 shall apply during the time /2- The output power shall be 
measured through the square root raised cosine filter with a roll off factor of 0,35 and a symbol duration of 500/9 )J,s as 
defined in clauses 5.5 and 5.6. 

6.4.5.1 BS 

The BS output power shall be at the nominal level, as specified in clause 6.4.1.1. Power control shall not be applied to 
the downlink transmissions. 

In the non-active transmit state the specification Lf^in = -40 dBc shall apply. 

The peak transmit power during BLCH shall not exceed +6 dBc. 

6.4.5.2 MS 

The MS output power shall be able to be reduced to levels defined in table 6.3, down to a minimum level of 15 dBm. 
The power levels that can be achieved, according to the class of the MS, are detailed in clause 6.4.1.2. 

During the non-active transmit state the specification L^;„ = -70 dBc or L^/„ = -36 dBm, whichever is greater, shall 
apply. 

6.4.6 Transmitter intermodulation attenuation for pinase modulation 

6.4.6.1 Definition 

The intermodulation attenuation is the ratio of the power level of the wanted signal to the power level of an 
intermodulation component. It is a measure of the capability of the transmitter to inhibit the generation of signals in its 
non-linear elements caused by the presence of the useful carrier and an interfering signal reaching the transmitter via its 
antenna. 

6.4.6.2 BS 

The intermodulation attenuation of the BS equipment shall be at least 70 dB for any intermodulation component when 
measured in a 30 kHz bandwidth. The interfering signal shall be un-modulated and have a frequency offset of at least 
500 kHz from the carrier frequency. The power level of the interfering signal shall be 30 dB below the power level of 
the modulated output signal from the transmitter under test. If the intermodulation attenuation is achieved by additional, 
internal or external, isolating devices they shall be included in the measurements. 

However, in the case of BS equipment with only one transmitter and which is not intended to be collocated with other 
radio equipment operating in the same frequency band, an intermodulation attenuation of at least 40 dB shall be 
sufficient. 

In any case no requirement less than -36 dBm shall apply to intermodulation components i.e. the power of any 
intermodulation component need not be less than -36 dBm. 
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All power levels stated in the cases above refer to the antenna connector of the BS described in clause 6.3. 



6.4.6.3 



MS 



In an MS, intermodulation may be caused when operating transmitters in the close vicinity of each other. 

For an MS transmitter operating at the nominal power defined by its class, the intermodulation attenuation shall be at 
least 60 dB for any intermodulation component when measured in 30 kHz bandwidth. The interfering signal shall be 
un-modulated and have a frequency offset of at least 500 kHz from the carrier frequency. The power level of the 
interfering signal shall be 50 dB below the power level of the modulated output signal from the transmitter under test. 

6.4.7 Intra-BS intermodulation requirements 

In a BS, intermodulation may be caused by combining several transmitters and carriers to feed a single antenna. 

For all transmitters of a single TETRA BS, the power of any intermodulation components, when measured in a 30 kHz 
bandwidth, shall not exceed -60 dBc in the relevant downlink frequency band. In any case no requirement less than 
-36 dBm shall apply i.e. the power of any intermodulation component need not be less than -36 dBm. 

NOTE: The value of -60 dBc refers to the carrier power of the transmitter with the highest output power 
measured at the antenna connector of the BS described in clause 6.3. 

In the case where the performance is achieved by additional internal or external isolating devices (such as circulators) 
they shall be supplied at the time of conformance testing and shall be used for measurements. 

6.4.8 Output power for QAM 

In clauses 6.4.8.1 and 6.4.8.2, power for QAM is defined as the sum of the powers of each of the sub-carriers within the 
RF channel bandwidth. For each sub-carrier, reference power is defined as the average power, measured at symbol time 
through the square root raised cosine filter defined in clause 5.16, over the pilot and sync symbols within the QAM 
burst as defined in clause 9. 

The powers at which MSs or BSs may operate are specified in clauses 6.4.8.1 and 6.4.8.2. 



6.4.8.1 



BS 



The BS transmitter nominal power shall be as defined in table 6.9 according to its power class. 

The power tolerances are defined in clause 7.1.1.2 of EN 300 394-1 [i.l3]. 

Each individual sub-carrier reference power shall be within +1 dB of the average sub-carrier reference power (total 
reference power divided by number of sub-carriers). For each individual sub-carrier containing pilot symbols, each pilot 
sub-carrier symbol power shall be within +1 dB of the average for that sub-carrier. 

Table 6.9: Nominal power of BS QAM transmitters 



Power class 


Nominal power per modulated RF carrier 
(see note) 


1 (40 W) 


46 dBm 


2 (25 W) 


44 dBm 


3(15W) 


42 dBm 


4(10W) 


40 dBm 


5 (6,3 W) 


38 dBm 


6(4W) 


36 dBm 


7(2,5W) 


34 dBm 


8(1,6W) 


32 dBm 


9(1 W) 


30 dBm 


10(0,6W) 


28 dBm 


NOTE: "Modulated RF carrier" has an RF channel bandwidth of 25 kHz, 

50 kHz, 1 00 kHz or 1 50 kHz, comprising 8, 1 6, 32 or 48 modulated 
sub-carriers respectively. 
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6.4.8.2 



MS 



The MS nominal power shall be as defined in table 6. 10 according to its power class. 

The power tolerances are defined in clause 6 of EN 300 394-1 [i.l3]. 

Each individual sub-carrier reference power shall be within +1 dB of the average sub-carrier reference power (total 
reference power divided by number of sub-carriers). For each individual sub-carrier containing pilot symbols, each pilot 
sub-carrier symbol power shall be within +1 dB of the average for that sub-carrier. 

Table 6.10: Nominal power of MS QAM transmitters 



Power class 


Nominal power 


1 (30 W) 


45dBm 


1L( 17,5 W) 


42,5 dBm 


2(10W) 


40dBm 


2L(5,6W) 


37,5 dBm 


3(3W) 


35 dBm 


3L(1,8W) 


32,5 dBm 


4(1 W) 


30 dBm 


4L(0,56W) 


27,5 dBm 


5 (0,32 W) 


25 dBm 


5L(0,18W) 


22,5 dBm 



The different power levels needed for adaptive power control (see clause 10.2) shall have the values as defined in 
table 6. 11, starting from the minimum power control level of 15 dBm (step level 7) up to the nominal power level 
corresponding to the class of the particular MS as stated in table 6.10. 

The power tolerances are defined in clause 6 of EN 300 394-1 [i.l3]. 

Table 6.11 : Nominal MS QAM power control levels 



Step level 


Power 


1 


45 dBm 


2 


40 dBm 


3 


35 dBm 


4 


30 dBm 


5 


25 dBm 


6 


20 dBm 


7 


15 dBm 



6.4.9 Unwanted conducted emissions for QAM 
6.4.9.1 Definitions 

The definitions in clause 6.4.2.1 apply. 



6.4.9.2 



Unwanted emissions close to the carrier 



The unwanted emissions in clauses 6.4.9.2.1 and 6.4.9.2.2 shall be measured through the square root raised cosine filter 
with a roll-off factor of 0,35 and a symbol duration of 500/9 |J,s, as defined in clauses 5.5 and 5.6. 

Measurements shall be done at the nominal centre frequency and at the frequency offsets specified in tables 6.12, 6.13, 
6.14 and 6.15. When applicable, relative measurements (dBc) shall refer to the power level measured at the nominal 
centre frequency as defined in clause 6.4.8. 
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6.4.9.2.1 



Emission during the useful part of the burst 



The levels given in tables 6.12, 6.13, 6.14 and 6.15 shall not be exceeded at the listed frequency offsets from the 
nominal carrier frequency. 

Table 6.12: Maximum adjacent power levels for 25 kHz QAM 



Frequency offset 


Maximum level for 
MS and BS 


25 kHz 


-55 dBc 


50 kHz 


-65 dBc 


75 kHz 


-67 dBc 



Table 6.13: Maximum adjacent power levels for 50 kHz QAM 



Frequency offset 


Maximum level for 
MS and BS 


37,5 kHz 


-55 dBc 


62,5 kHz 


-63 dBc 


87,5 kHz 


-65 dBc 



Table 6.14: Maximum adjacent power levels for 100 kHz QAM 



Frequency offset 


Maximum level for 
MS and BS 


62,5 kHz 


-55 dBc 


87,5 kHz 


-60 dBc 


112,5 kHz 


-60 dBc 



Table 6.15: Maximum adjacent power levels for 150 kHz QAM 



Frequency offset 


Maximum level for 
MS and BS 


87,5 kHz 


-55 dBc 


112,5 kHz 


-60 dBc 


137,5 kHz 


-60 dBc 



In any case, no requirement less than -36 dBm shall apply i.e. the maximum power level need not be less than -36 dBm. 

The specifications assume that the centre frequency is at the above listed frequency offsets from the nominal carrier 
frequency. The measured values shall be averaged over the useful part of the burst (see clause 9). The scrambled bits 
shall have a pseudo-random distribution from burst to burst. 



6.4.9.2.2 



Emission during the switching transients 



At the frequency offset from the nominal carrier frequency given below, peak power measurements shall be done, 
covering at least the ramp-up period and the ramp-down period (figure 6.4, periods tj and t^) (see clause 6.4.10 for 
definition of tj and f^). 

For 25 kHz QAM the maximum hold level of -45 dBc at a frequency offset of 25 kHz shall not be exceeded. 
For 50 kHz QAM the maximum hold level of -45 dBc at a frequency offset of 37,5 kHz shall not be exceeded. 
For 100 kHz QAM the maximum hold level of -45 dBc at a frequency offset of 62,5 kHz shall not be exceeded. 
For 150 kHz QAM the maximum hold level of -45 dBc at a frequency offset of 87,5 kHz shall not be exceeded. 
This requirement does not apply to linearization channels. 
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In any case no requirement less than -36 dBm shall apply i.e. the maximum peak power level need not be less than 
-36 dBm. 



6.4.9.3 



Unwanted emissions far from the carrier 



These unwanted emissions are emissions (discrete, wideband noise, modulated or un-modulated) occurring at offsets of 
equal to, or greater than, 100 kHz from the carrier frequency, measured in the frequency range 9 kHz to 4 GHz. 

a) Discrete spurious: 

the maximum allowed power for each spurious emission shall be less than -36 dBm measured in 
100 kHz bandwidth in the frequency range 9 kHz to 1 GHz and -30 dBm measured in 1 MHz bandwidth 
in the frequency range 1 GHz to 4 GHz (1 GHz to 12,75 GHz for equipment capable of operating at 
frequencies above 470 MHz). Specific measurement method are required both when measuring within 
-frh of carrier frequency, due to the presence of wideband noise, and in the lower part of the spectrum. 

b) Wideband noise: 

the wideband noise levels, measured through the modulation filter defined in clause 5.6 should not 
exceed the limits shown in tables 6.16, 6.17, 6.18 and 6.19, for the nominal power levels as stated, and at 
the listed offsets from the nominal carrier frequency. When applicable, relative measurements (dBc) shall 
refer to the power level measured at the nominal centre frequency as defined in clause 6.4.8. The 
requirements apply symmetrically to both sides of the transmitter band. 

Table 6.16: Wideband noise limits 25 kHz QAM 



Frequency offset 


Maximum wideband noise level for MS and BS | 


MS nominal 

power level 

< 1 W (class 4) 


MS nominal power 

level = 1 ,8 W or 3 W 

(class 3L or 3) 


MS nominal power level 

> 5,6 W (class 2L) 

BS all classes 


100 kHz to 250 kHz 


-70 dBc 


-70 dBc 


-70 dBc 


250 kHz to 500 kHz 


-74 dBc 


-74 dBc 


-80 dBc 


500 kHz to 2 500 kHz 


-80 dBc 


-80 dBc 


-80 dBc 


2500kHz to frb 


-80 dBc 


-80 dBc 


-90 dBc 


> frb 


-95 dBc 


-95 dBc 


-95 dBc 


NOTE: fi-tj denotes the frequency offset corresponding to the near edge of the receive band or 5 IVIHz 
(10 IVIHz for frequencies above 520 IVlHz) whichever is greater. 



Table 6.17: Wideband noise limits 50 kHz QAM 



Frequency offset 


Maximum wideband noise level for MS and BS | 


MS nominal 

power level 

< 1 W (class 4) 


MS nominal power 

level = 1 ,8 W or 3 W 

(class 3L or 3) 


MS nominal power level 

> 5,6 W (class 2L) 

BS all classes 


11 2,5 kHz to 262,5 kHz 


-68 dBc 


-68 dBc 


-70 dBc 


262,5 kHz to 500 kHz 


-72 dBc 


-72 dBc 


-75 dBc 


500 kHz to frb 


-78 dBc 


-78 dBc 


-80 dBc 


> frb 


-95 dBc 


-95 dBc 


-95 dBc 


NOTE: frb denotes the frequency offset corresponding to the near edge of the receive band or 5 IVIHz 
(10 MHz for frequencies above 520 IVIHz) whichever is greater. 
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Table 6.18: Wideband noise limits 100 kHz QAM 



Frequency offset 


Maximum wideband noise level for MS and BS | 


MS nominal power level < 3 W 
(class 3) 


MS nominal power level 

> 5,6 W (class 2L) 

BS all classes 


137,5 kHz to 287,5 kHz 


-60 dBc 


-70 dBc 


287,5 kHz to 537,5 kHz 


-65 dBc 


-70 dBc 


537,5 kHz to 1000 kHz 


-73 dBc 


-75 dBc 


1000kHz to f^b 


-73 dBc 


-80 dBc 


>frb 


-95 dBc 


-95 dBc 


NOTE: frb denotes the frequency offset corresponding to the near edge of the receive band or 5 IVIHz 
(10 IVIHz for frequencies above 520 IVIHz) whichever is greater. 



Table 6.19: Wideband noise limits 150 kHz QAM 



Frequency offset 


Maximum wideband noise level for MS and BS | 


MS nominal power level < 3 W 
(class 3) 


MS nominal power level 

> 5,6 W (class 2L) 

BS all classes 


162,5 kHz to 31 2,5 kHz 


-60 dBc 


-60 dBc 


31 2,5 kHz to 562,5 kHz 


-63 dBc 


-70 dBc 


562,5 kHz to 1500 kHz 


-70 dBc 


-75 dBc 


1 500 kHz - frb 


-70 dBc 


-80 dBc 


> frb 


-95 dBc 


-95 dBc 


NOTE: ffb denotes the frequency offset corresponding to the near edge of the receive band or 5 MHz 
(10 MHz for frequencies above 520 MHz) whichever is greater. 



All levels in tables 6.16 to 6.19 are expressed in dBc relative to the actual transmitted power level, and in any case no 
limit tighter than -55 dBm for offsets <frb or -70 dBm for offsets >frb shall apply. 



6.4.9.4 



Unwanted emissions during the CLCH-Q and BLCH-Q 



The following emissions shall be measured through a square root raised cosine filter with a roll-off factor of 0,35 and 
symbol duration of 500/9 jis as defined in clauses 5.5 and 5.6. 

For 25 kHz QAM the sum of the time periods during which the peak power, at a frequency offset of +25 kHz during the 
BLCH-Q/CLCH-Q, is above -45 dBc shall not exceed 1ms. This peak power shall never exceed -30 dBc. 

For 50 kHz QAM the sum of the time periods during which the peak power, at a frequency offset of +37,5 kHz during 
the BLCH-Q/CLCH-Q, is above -45 dBc shall not exceed 1ms. This peak power shall never exceed -30 dBc. 

For 100 kHz QAM the sum of the time periods during which the peak power, at a frequency offset of +62,5 kHz during 
the BLCH-Q/CLCH-Q, is above -45 dBc shall not exceed 1ms. This peak power shall never exceed -30 dBc. 

For 150 kHz QAM the sum of the time periods during which the peak power, at a frequency offset of +87,5 kHz during 
the BLCH-Q/CLCH-Q, is above -43 dBc shall not exceed 1ms. This peak power shall never exceed -30 dBc. 

NOTE: dBc refers to the transmit power during normal operation after the CLCH-Q or BLCH-Q. 

6.4.9.5 Unwanted emissions in the non-transmit state 

The specifications of clause 6.5.4.2 apply. 

6.4.1 RF Output power time mask for QAM 

The QAM transmit level versus time mask for TETRA mobile station transmission is shown in figure 6.4 and 
table 6.20. For the time mask the power level of dBc refers to the output power level of the TETRA mobile station 
under consideration. Unwanted emissions due to switching transients are specified in clause 6.4.9.2.2. 
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Tx level 




Symbol time of SA/, symbol time of SNmax 

Figure 6.4: Transmit level versus time mask for QAM 

Table 6.20: Transmit level versus time mask symbol durations (refer figure 6.4) 



Burst Type 


tl 


t2 


t3 


Control / random access uplink 


2,0 


13,0 


2,5 


Linearization uplink 


15,0 


0,0 


2,5 


Normal uplink 


2,0 


30,0 (note) 


2,5 


NOTE: In the case of single slot transmission. 



Whenever bursts are consecutively transmitted by the same TETRA mobile station on the same frequency, the transmit 
level versus time mask applies at the beginning of the transmission of the first burst and at the end of the transmission 
of the last burst. 

The symbol numbers referred to as SN-Ql and SN-Qmax are defined in clause 9 for QAM. The timing of the 
transmitted bursts is specified in clause 7 for QAM. The time periods f;, t2 and fj, whose durations are stated in 
table 6.20, are defined in the following way: 

• the time f; starts at the beginning of the ramp-up of the first burst, and expires just before the symbol time of 
SN-Ql- 

• the time t2 starts at the symbol time of SN-Ql of the first burst and finishes at the symbol time of SN-Qmax of 
the last burst; 

• the time t^ starts just after the symbol time of SN-Qmax of the last burst and finishes at the end of the ramp- 
down. 

In this clause, the specifications of clauses 6.4.8 and 6.7.1.2 shall apply during the time t2- 

6.4.10.1 BS 

The BS QAM output power shall be at the nominal level, as specified in clause 6.4.8.1, excluding linearization bursts. 
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6.4.10.2 MS 



The MS QAM output power shall be able to be reduced to levels defined in table 6. 11, down to a minimum level of 
15 dBm. The power levels that can be achieved, according to the class of the MS, are detailed in clause 6.4.8.2. 

During the non-active transmit state the specification Lyy^in = -70 dBc or Lf^in = -36 dBm, whichever is greater, shall 
apply. 

6.4.1 1 Transmitter intermodulation attenuation 

Requirements in clause 6.4.6 apply. 

6.4.12 Intra-BS intermodulation requirements 

Requirements in clause 6.4.7 apply. 

6.5 Receiver characteristics 

In this clause, the levels of the test signals are given in terms of power levels (dBm) at the antenna connector of the 
receiver. For the definition of power level refer to clauses 6.4.1 and 6.4.8. 

Sources of test signals shall be connected in such a way that the impedance presented to the receiver input is a 50 Q 
non-reactive impedance. 

This requirement shall be met irrespective of whether one or more signals using a combining network are applied to the 
receiver simultaneously. 

Static propagation conditions are assumed in all cases, for both wanted and unwanted signals. 

6.5.1 Blocking characteristics 

6.5.1.1 Definition 

Blocking is a measure of the capability of the receiver to receive a modulated wanted input signal in the presence of an 
unwanted un-modulated input signal on frequencies other than those of the spurious responses or the adjacent channels, 
without this unwanted input signal causing a degradation of the performance of the receiver beyond a specified limit. 

6.5.1 .2 Specification for Phase Modulation 

The blocking performance specification given in table 6.21 shall apply at all frequencies except those at which spurious 
responses occur (see clause 6.5.2). 

Table 6.21 : Blocking levels of the receiver 



Offset from nominal Rx freq. 


Level of Interfering signal 


50 kHz to 100 kHz 


-40 dBm 


100 kHz to 200 kHz 


-35 dBm 


200 kHz to 500 kHz 


-30 dBm 


> 500 kHz 


-25 dBm 



The static reference sensitivity performance as specified in clause 6.6.2.4 shall be met when the following signals are 
simultaneously input to the receiver: 

• a wanted signal at the nominal receive frequency /p, 3 dB above the static reference sensitivity level as 
specified in clause 6.6.2.4; 

• a continuous sine wave signal at a frequency offset from/^ and level as defined in table 6.21. 
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6.5.1.3 



Specification for QAM 



The blocking performance specification given in tables 6.22, 6.23, 6.24 and 6.25 shall apply at all frequencies except 
those at which spurious responses occur (see clause 6.5.2). 

Table 6.22: Blocking levels of the 25 kHz (8 subchannels) QAM receiver 



Offset from nominal Rx freq. 


Level of interfering signal 


50 kHz to 100 kHz 


-40 dBm 


100 kHz to 200 kHz 


-35 dBm 


200 kHz to 500 kHz 


-30 dBm 


> 500 kHz 


-25 dBm 



Table 6.23: Blocking levels of the 50 kHz (16 subchannels) QAM receiver 



Offset from nominal Rx freq. 


Level of Interfering signal 


100 kHz to 200 kHz 


-40 dBm 


200 kHz to 400 kHz 


-35 dBm 


400 kHz to 1 000 kHz 


-30 dBm 


> 1 000 kHz 


-25 dBm 



Table 6.24: Blocking levels of the 100 kHz (32 subchannels) QAM receiver 



Offset from nominal Rx freq. 


Level of Interfering signal 


200 kHz to 400 kHz 


-40 dBm 


400 kHz to 600 kHz 


-35 dBm 


600 kHz to 1 000 kHz 


-30 dBm 


> 1 000 kHz 


-25 dBm 



Table 6.25: Blocking levels of the 150 kHz (48 subchannels) QAM receiver 



Offset from nominal Rx freq. 


Level of Interfering signal 


300 kHz to 500 kHz 


-40 dBm 


500 kHz to 800 kHz 


-35 dBm 


800 kHz to 1 000 kHz 


-30 dBm 


> 1 000 kHz 


-25 dBm 



The static reference sensitivity performance as specified in clause 6.7.2.4 shall be met when the following signals are 
simultaneously input to the receiver: 

• a wanted signal at the nominal receive frequency /p, 3 dB above the static reference sensitivity level as 
specified in clause 6.7.2.4; 

• a continuous sine wave signal at a frequency offset from/^ and level as defined in tables 6.22, 6.23, 6.24 and 
6.25. 



6.5.2 Spurious response rejection 



6.5.2.1 



Definition 



Spurious response rejection is a measure of the capability of a receiver to receive a wanted modulated signal without 
exceeding a given degradation due to the presence of an unwanted un-modulated signal at any other frequency at which 
a response is obtained, i.e. for which the blocking limit is not met. 
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6.5.2.2 Specification for phase modulation 

a) The static reference sensitivity performance as specified in clause 6.6.2.4 shall be met when the following 
signals are simultaneously applied to the receiver: 

a wanted signal at nominal receive frequency Z^, 3 dB above the static reference sensitivity level as 
specified in clause 6.6.2.4; 

a continuous sine wave signal with any offset from nominal Rx frequency > 50 kHz at a level of 
-45 dBm. 

b) The number of frequencies within a limited frequency range, defined below, at which the blocking 
specification of clause 6.5.1.2 is not met shall not exceed 0,05 X (number of frequency channels in the limited 
frequency range). 

The limited frequency range is defined as the frequency of the local oscillator signal //„ applied to the first mixer of the 
receiver plus or minus the sum of the intermediate frequencies (/);,.....//„) and a half of the switching range (sr) of the 
receiver. 

Hence the frequency/; of the limited frequency range is: 

fio-i:fij-%<fi<fio+Tfij + % 

j=^ ^=^ (6.2) 

Where receiver switching range (sr) is the maximum frequency range over which the receiver can be operated without 
reprogramming or realignment as declared by the manufacturer. 

6.5.2.3 Specification for QAM 

a) The static reference sensitivity performance as specified in clause 6.7.2.4 shall be met when the following 
signals are simultaneously applied to the receiver: 

a wanted signal at nominal receive frequency /p, 3 dB above the static reference sensitivity level as 
specified in clause 6.7.2.4; 

a continuous sine wave signal with any offset from nominal Rx frequency > fspur at a level of -45 dBm. 
Fspur value is defined in table 6.26. 

Table 6.26: Continuous sine wave offset frequency fspur 



QAM Channel bandwidth 


Offset from nominal Rx freq. 


25 kHz 


50 kHz 


50 kHz 


100 kHz 


100 kHz 


200 kHz 


150 kHz 


300 kHz 



b) The number of frequencies within a limited frequency range, defined below, at which the blocking 

specification of clause 6.5.1.3 is not met shall not exceed 0,05 x (number of frequency channels in the limited 
frequency range). 

The limited frequency range is defined as the frequency of the local oscillator signal //^ applied to the first mixer of the 
receiver plus or minus the sum of the intermediate frequencies (/);,.....//„) and a half of the switching range (sr) of the 
receiver. 

Hence the frequency/; of the limited frequency range is: 

fio-i:fij-%<fi<fio+ifij + % 

j=^ ^=^ (6.3) 
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Where receiver switching range (sr) is the maximum frequency range over which the receiver can be operated without 
reprogramming or realignment as declared by the manufacturer. 



6.5.3 Intermodulation response rejection 



6.5.3.1 



Definition 



Intermodulation response rejection is a measure of the capability of the receiver to receive a wanted modulated signal 
without exceeding a given degradation due to the presence of two or more unwanted signals with a specific frequency 
relationship to the wanted signal frequency as defined in EN 300 113-1 [4]. 

6.5.3.2 Specification for Phase Modulation 

The static reference sensitivity performance as specified in clause 6.6.2.4 shall be met when the following signals are 
simultaneously input to the receiver: 

• a wanted signal at the nominal receive frequency /p, 3 dB above the static reference sensitivity level; 

• a continuous sine wave signal at frequency /j and with a level of -47 dBm; 

• a pseudo-random sequence TETRA 7t/4-DQPSK modulating a signal at frequency /2, with a level of -47 dBm, 
such that/„ = 2/j -/j and I/2 -/jl = 200 kHz. 



6.5.3.3 



Specification for QAM 



The static reference sensitivity performance as specified in clause 6.7.2.4 shall be met when the following signals are 
simultaneously input to the receiver: 

• a wanted signal at the nominal receive frequency /p, 3 dB above the static reference sensitivity level; 

• a continuous sine wave signal at frequency /j and with a level of -47 dBm; 

• a pseudo-random sequence TETRA 7t/4-DQPSK modulating a signal at frequency /2, with a level of -47 dBm, 
such that/g = 2fi -/2 and 1/2 - /jl = f^- Where /^ is defined in table 6.27. 

Table 6.27: f^ definition 



QAM Channel bandwidth 


Offset from nominal Rx freq. 


25 kHz 


200 kHz 


50 kHz 


400 kHz 


100 kHz 


800 kHz 


150 kHz 


1 200 kHz 



6.5.4 Unwanted conducted emissions 



6.5.4.1 



Definition 



Unwanted emissions from the equipment when in reception are defined as conducted emissions at any frequency, when 
the equipment is in the non-transmit state. 



6.5.4.2 



Specification 



The peak power emitted by the equipment shall not exceed -57 dBm at frequencies between 9 kHz and 1 GHz, as 
measured in a bandwidth of 100 kHz. 

For equipment only capable of operating below 470 MHz the power emitted by the equipment shall not exceed -47 dBm 
from 1 GHz to 4 GHz, as measured in a bandwidth of 1 MHz. 
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For equipment capable of operating above 470 MHz the power emitted by the equipment shall not exceed -47 dBm 
from 1 GHz to 12,75 GHz, as measured in a bandwidth of 1 MHz. 

6.5.5 Unwanted radiated emissions 

Unwanted radiated emissions are emissions radiated by the cabinet and structure of the equipment (MS or BS) in the 
non-transmit state. This is also known as cabinet radiation. 

The limits given in clause 6.5.4.2 shall apply for frequencies between 30 MHz and 4 GHz only. 

6.6 Transmitter/receiver performance for pinase modulation 

Clause 6.6.1 specifies the modulation accuracy requirement, by setting limits on the Root Mean Square (RMS) error 
between the actual transmitted signal waveform and the ideal signal waveform. Clause 6.6.2 specifies the receiver 
performance, assuming that transmit errors do not occur. Clause 6.8 specifies all the propagation models that are 
defined in the present document. 

6.6.1 Transmitter performance for pinase modulation 

6.6.1 .1 Modulation accuracy for phase modulation 

The specified requirement is vector error magnitude; this does not only take into account modulation filtering linear 
distortion (amplitude and phase) or modulator impairments (quadrature offset, phase and linear amplitude errors in the 
modulation symbol constellation) but is a measure of the whole transmitter quality. It also takes into account local 
oscillator phase noise, filter distortion, and non-linearity of amplifiers. Vector error magnitude shall be specified at 
symbol time (see clause 6.6.1.2) and the vector error magnitude requirement shall be fulfilled by the TETRA equipment 
with maximum and with minimum power levels (as defined in clause 6.4.1). 

The modulation symbol s(t) transmitted by an ideal transmitter having a filter impulse response g(t) is defined in 
clause 5. 

Let Z(k) denote the output of an ideal receive filter with impulse response: 

^ '^t=t^ (6.4) 

The ideal transmit and receive filters in cascade form a raised cosine Nyquist filter, having a symbol waveform going 
through zero at symbol duration intervals, so there is no inter-symbol interference at any instant t = tj^, where f^ is the 
symbol time corresponding to the A:-th symbol (as defined in clause 5). 

In this case, the output of an ideal receive filter at any instant tj^, stimulated by an ideal transmitter, will be equal to the 
fc-th modulation symbol S(ky. 

Z(k) = s{tyg{-t)\ =S{k) (6.5) 

n — lf^ 

In this clause, the numbering of the modulation symbols used is the one defined in clause 9. 

6.6.1 .2 Vector error magnitude requirement at symbol time for phase modulation 

Let Z(k) be the output produced by observing the real transmitter through the ideal receive filter at symbol time ti^ x Z(k) 
is modelled as: 



z{k) = [Co + [s{k) + E{k)]}cM'<) ^^-^^ 
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Where: 



• E(k) is the vector error of modulation symbol S(ky, 

• W(k) = exp(jk0) accounts for a frequency offset giving radians per symbol phase rotation due to transmitter 
frequency inaccuracy (see clause 7). The possible amplitude variations shall be integrated in the vector error; 

• Co is a complex constant characterizing the residual carrier; 

• C; is a complex constant representing the output amplitude and initial phase of the transmitter. 
The magnitude of Cq shall be less than 5 % of the magnitude of S(k). The task of the test receiver is then to: 

• estimate the symbol time for processing the receive part; 

• estimate the values of Cq, Cj and 0. The resulting estimates shall be denoted by Cq, Cj ' and 0'respectively; 

• perform a normalization of the modulation symbol Z(k) accordingly. The modulation symbol that results from 
this normalization shall be denoted by Zffej: 



Z'ik] 



Z[k)exp{-jk0')IC, 



(6.7) 



With the above notations, the Sum Square Vector Error (SSVE) is defined as: 



SNmax , ^ 

SSVE= I Z'{k)-S{k) (6.8) 

k=1 

Where SNmax is the number of symbols in the burst. 

The RMS vector error is then computed as the square root of the sum-square vector error divided by the number of 
symbols in the burst: 



RMSVE-^SSVE/^^^^ (6.9) 

The RMS vector error in any burst shall be less than 0,1 and the peak vector error magnitude \Z'(k)-S(k)\ shall be less 
than 0,3 for any symbol. 

6.6.2 Receiver performance for phase modulation 

This clause specifies the minimum required receiver performance in terms of Bit Error Ratio (BER), Message Erasure 
Rate (MER) or Probability of Undetected Erroneous Message (PUEM) (whichever is appropriate), taking into account 
that transmitter errors do not occur, and that the transmitter shall be tested separately (see clause 6.6.1). 

In this clause, the levels of the test signals are given in terms of power levels (dBm) at the antenna connector of the 
receiver. For the definition of power level refer to clause 6.4.1. 

Three equipment classes are specified, distinguishing their intended operating environments and testing conditions. The 
classes have preferred operating conditions, as follows: 



• 



Class B: equipment is optimized for use in built-up and urban areas. The present document guarantees good 
performance at the reference sensitivity and interference level in static and TU50 conditions, but not in 
extreme propagation conditions (hilly terrain); 

Class A: equipment is optimized for use in urban areas and in areas with hilly or mountainous terrain. It is 
resilient to extreme propagation conditions (hilly terrain) and is specified in static, TU50 and HT200 
conditions; 

Class D: equipment has the same performance requirements as class A for 7t/4-DQPSK modulation, and is 
further optimized to enhance the performance of 71/8-D8PSK modulation in hilly or mountainous terrain using 
equalization or other techniques. It is resilient to extreme propagation conditions (hilly terrain) and is specified 
in static, TU50 and HT200 conditions; 
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• Class E: equipment comprises an equalizer and is specified for 71/4-DQPSK modulation in static, TU50, 
HT200 (PACQ only) and EQ200 conditions. It is not applicable to BS equipment. Class E performance is 
specified only for 7i/4-DQPSK modulation. 



6.6.2.1 



Nominal error rates for phase modulation 



6.6.2.1.1 



Nominal error rates for 7i/4-DQPSK modulation 



This clause describes the transmission requirements in terms of error ratios in nominal conditions i.e. without 
interference and with an input level of -85 dBm. The relevant propagation conditions are given in clause 6.8. 

Under the following propagation conditions, the BER of the non-protected bits, equivalent to the TCH/7,2 shall have 
the limits given in table 6.28. 

Table 6.28: Nominal error rates 



Propagation model 


BER 


Equipment class 


STATIC 


0,01 % 


A, B, E 


TU50 


0,4 % 


A, B, E 


HT200 


3% 


A 


EQ200 


2% 


E 



This performance shall be maintained up to -40 dBm input level for the static conditions, and multipath conditions. 
Furthermore, for static conditions, a BER of < 0, 1 % shall be maintained up to -20 dBm. 



6.6.2.1.2 



Nominal error rates for 71/8-D8PSK modulation 



This clause describes the transmission requirements in terms of error ratios in nominal conditions i.e. without 
interference and with an input level of -85 dBm. The relevant propagation conditions are given in clause 6.8. 

Under the following propagation conditions, the BER of the non-protected bits, equivalent to the TCH-P8/10,8 shall 
have the limits given in table 6.29. 

Table 6.29: Nominal error rates 



Propagation model 


BER 


Equipment class 


STATIC 


0,01 % 


A, B, D 


TU50 


0,4 % 


A, B, D 


HT200 


5% 


A, D 



This performance shall be maintained up to -40 dBm input level for the static conditions, and multipath conditions. 
Furthermore, for static conditions, a BER of < 0, 1 % shall be maintained up to -20 dBm. 



6.6.2.2 



Dynamic reference sensitivity performance for phase modulation 



The minimum required dynamic reference sensitivity performance is specified according to the logical channel, the 
propagation condition and the receiver class at the dynamic reference sensitivity level. The dynamic reference 
sensitivity level shall be: 

• for MS 7t/4-DQPSK modulation: -103 dBm; 

• for MS 7t/8-D8PSK modulation: -97 dBm; 

• for BS 7t/4-DQPSK modulation: -106 dBm; 

• for BS 7t/8-D8PSK modulation: -100 dBm. 
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Tables 6.30 and 6.32 give the maximum permissible receiver MER or BER at dynamic reference sensitivity 
performance for TU50, HT200 or EQ200 propagation conditions with 7t/4-DQPSK modulation. For BSCH, SCH/HD, 
SCH/HU, SCH/F and BNCH, a PUEM < lO'^ shall be achieved at the 7t/4-DQPSK dynamic reference sensitivity level. 
For AACH, a PUEM < 10'^ shall be achieved at the 7t/4-DQPSK dynamic reference sensitivity level. 

Tables 6.31 and 6.33 give the maximum permissible receiver MER or BER at dynamic reference sensitivity 
performance for TU50 or HT200 propagation conditions with 7t/8-D8PSK modulation. For SCH-P8/HD, SCH-P8/HU 
and SCH-P8/F, a PUEM < 10'^ shall be achieved at the 7t/8-D8PSK dynamic reference sensitivity level. 



6.6.2.2.1 



BS receiver performance 



Table 6.30 gives the maximum permissible receiver MER or BER at dynamic reference sensitivity performance with 
TC/4-DQPSK modulation. 

Table 6.30: Maximum permissible BS receiver MER or BER 
at dynamic reference sensitivity level with 7i/4-DQPSK modulation 







Class A 


Class B 


Logical channel 


Error count 
type 


Propagation condition 


Propagation 
condition 


TU50 


HT200 


TU50 


SCH/HU 


MER 


8% 


9,5 % 


8% 


SCH/F 


MER 


11 % 


11 % 


8% 


TCH/7,2 


BER 


2,5 % 


4% 


2,2 % 


TCH/4,8 N = 1 


BER 


4% 


4% 


2% 


TCH/4,8 N = 4 


BER 


1 ,2 % 


4% 


0,4 % 


TCH/4,8 N = 8 


BER 


0,4 % 


4% 


0,06 % 


TCH/2,4 N = 1 


BER 


1 ,2 % 


1 ,3 % 


0,35 % 


TCH/2,4 N = 4 


BER 


0,02 % 


0,3 % 


0,01 % 


TCH/2,4 N = 8 


BER 


0,01 % 


0,15% 


0,01 % 


STCH 


MER 


9% 


11 % 


8% 


NOTE: N gives the interleaving deptli in number of blocks (see clause 8). 



Table 6.31 gives the maximum permissible receiver MER or BER at dynamic reference sensitivity performance with 
7t/8-D8PSK modulation. 

Table 6.31 : Maximum permissible BS receiver MER or BER 
at dynamic reference sensitivity level with 71/8-D8PSK modulation 







Class A, class D 


Class B 


Logical 
channel 


Error count 
type 


Propagation condition 


Propagation condition 


TU50 classes A and D 


HT200 Class A 


HT200 Class D 


TU50 


SCH-P8/HU 


MER 


7,4 % 


19% 


14% 


6,3 % 


SCH-P8/F 


MER 


10% 


29% 


18% 


8,9 % 


TCH-P8/10,8 


BER 


1 ,6 % 


4,5 % 


3,6 % 


1 ,4 % 
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6.6.2.2.2 



MS receiver performance 



Table 6.32 gives the maximum permissible receiver MER or BER at dynamic reference sensitivity performance with 
7t/4-DQPSK modulation. 

Table 6.32: Maximum permissible MS receiver MER or BER 
at dynamic reference sensitivity level with 7i/4-DQPSK modulation 



Logical 
channel 


Error 
count 
type 


Continuous downlink mode 


Discontinuous downlink 
mode 


Propagation 
condition 


Propagation condition 


Propagation condition 


TU50 


HT200 


EQ200 


TU50 


HT200 


TU50 


Class A, E 


Class A 


Class E 


Class A 


Class A 


Class B 


AACH 


MER 


10% 


17% 


16% 


10% 


17% 


11 % 


BSCH 


MER 


8% 


11 % 


22% 


8% 


11 % 


8% 


SCH/HD 


MER 


8% 


11 % 


21 % 


9% 


11 % 


8% 


BNCH 


MER 


8% 


11 % 


21 % 


9% 


11 % 


8% 


SCH/F 


MER 


8% 


11 % 


22% 


11 % 


11 % 


8% 


TCH/7,2 


BER 


2,5 % 


4% 


4,5 % 


2,5 % 


4% 


2,2 % 


TCH/4,8 N = 1 


BER 


2% 


4% 


6,4 % 


4% 


4% 


2% 


TCH/4,8 N = 4 


BER 


0,4 % 


3,3 % 


2,7 % 


1 ,2 % 


4% 


0,4 % 


TCH/4,8 N = 8 


BER 


0,06 % 


3% 


1 ,5 % 


0,4 % 


4% 


0,06 % 


TCH/2,4 N = 1 


BER 


0,35 % 


1,1 % 


0,82 % 


1 ,2 % 


1 ,3 % 


0,35 % 


TCH/2,4 N = 4 


BER 


0,01 % 


0,4 % 


0,017% 


0,02 % 


0,4 % 


0,01 % 


TCH/2,4 N = 8 


BER 


0,01 % 


0,13% 


0,01 % 


0,01 % 


0,2 % 


0,01 % 


STCH 


MER 


8% 


11 % 


21 % 


9% 


11 % 


8% 


NOTE 1 : N gives the interleaving deptli in number of blocks (see clause 8). 

NOTE 2: Class B receiver performance are for both Continuous and Discontinuous downlink mode. 



Table 6.33 gives the maximum permissible receiver MER or BER at dynamic reference sensitivity performance with 
7t/8-D8PSK modulation. 

Table 6.33: Maximum permissible MS receiver MER or BER 
at dynamic reference sensitivity level with 71/8-D8PSK modulation 



Logical 
channel 


Error 
count 
type 


Continuous downlink mode 


Discontinuous downlink mode 


Propagation 
condition 


propac 


ation condition 


propagation condition 




TU50 


HT200 


HT200 


TU50 


HT200 


HT200 


TU50 


Class A, D 


Class A 


Class D 


Class A, D 


Class A 


Class D 


Class B 


SCH-P8/HD 


MER 


8,3 % 


21 % 


15% 


8,1 % 


21 % 


15% 


7,1 % 


SCH-P8/F 


MER 


10% 


29% 


18% 


10% 


29% 


18% 


9,0 % 


TCH-P8/10,8 


BER 


1 ,6 % 


4,5 % 


3,4 % 


1 ,6 % 


4,5 % 


3,6 % 


1 ,4 % 



£75/ 



95 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

6.6.2.3 Receiver performance at reference interference ratios for Phase Modulation 

The minimum required reference interference performance (for co-channel, C/Ic, or adjacent channel, C/I^) is specified 
according to the logical channel, the propagation condition and the receiver class at the reference interference ratio. The 
reference interference ratio shall be, for BS and all types of MS for 7t/4-DQPSK modulation: 

• for co-channel interference C/l^ = 19 dB for MS and BS; 

• for adjacent channel interference below 700MHz C/I^ = -40 dB for MS and 

C/4 = -45dBforBS; 

• for adjacent channel interference above 700MHz C//^ = -40 dB for MS and BS. 
The reference interference ratio shall be, for BS and all types of MS for 7t/8-D8PSK modulation: 

• for co-channel interference C//c = 25 dB for MS and BS; 

• for adjacent channel interference below 700MHz C/Ia = -34 dB for MS and 

C/4 = -39dBforBS; 

• for adjacent channel interference above 700MHz C/Ia = -34 dB for MS and BS. 

In case of co-channel interference these specifications apply for a wanted input signal level of -85 dBm, and in case of 
adjacent channel interference for a wanted input signal level 3 dB above the dynamic reference sensitivity level. In case 
of co-channel interference the interference shall be a continuous TETRA random signal of the same modulation type 
subjected to an independent realization of the same propagation condition as the wanted signal. In the case of adjacent 
channel interference the interference shall be a continuous TETRA random modulated signal of the same modulation 
type subjected to static propagation conditions. 

In tables 6.34 and 6.36 the performance for TU50, HT200 or EQ200 propagation conditions is given for the reference 
interference level. For BSCH, SCH/HD, SCH/HU, SCH/F, BNCH, a PUEM < 10-5 shall be achieved at the 
7t/4-DQPSK reference interference level. For AACH a PUEM < 10'^ shall be achieved at the 7t/4-DQPSK reference 
interference level. 

In tables 6.35 and 6.37 the performance for TU50 or HT200 propagation conditions is given for the reference 
interference level. For SCH-P8/HD, SCH-P8/HU and SCH-P8/F, a PUEM < 10-^ shall be achieved at the 7t/8-D8PSK 
reference interference level. 
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6.6.2.3.1 



BS receiver performance 



Table 6.34 gives the maximum permissible receiver MER or BER at reference interference with 7t/4-DQPSK 
modulation. 

Table 6.34: Maximum permissible BS receiver MER or BER 
at reference interference level with 7i/4-DQPSK modulation 







Class A 


Class B 


Logical channel 


Error count 
type 


Propagation condition 


Propagation 
condition 


TU50 


HT200 


TU50 


SCH/HU 


MER 


6,5 % 


9,5 % 


6,5 % 


SCH/F 


MER 


6% 


9,2 % 


6% 


TCH/7,2 


BER 


2% 


3,7 % 


2% 


TCH/4,8 N= 1 


BER 


4% 


4% 


2% 


TCH/4,8 N= 4 


BER 


1 ,2 % 


4% 


0,4 % 


TCH/4,8 N= 8 


BER 


0,4 % 


4% 


0,06 % 


TCH/2,4 N= 1 


BER 


1 ,2 % 


1 ,3 % 


0,35 % 


TCH/2,4 N= 4 


BER 


0,02 % 


0,3 % 


0,01 % 


TCH/2,4 N= 8 


BER 


0,01 % 


0,15% 


0,01 % 


STCH 


MER 


7% 


9,2 % 


7% 


NOTE: N gives the interleaving deptli in number of blocks (see clause 8). 



Table 6.35 gives the maximum permissible receiver MER or BER at reference interference with 7t/8-D8PSK 
modulation. 

Table 6.35: Maximum permissible BS receiver MER or BER 
at reference interference level with 71/8-D8PSK modulation 







Class A 


Class B 


Class D 


Logical channel 


Error 
count 
type 


propagation condition 


propagation 
condition 


propagation condition 


TU50 


HT200 


TU50 


TU50 


HT200 


SCH-P8/HU 


MER 


7,3 % 


19% 


6,6 % 


7,3 % 


13% 


SCH-P8/F 


MER 


10% 


29% 


9,1 % 


10% 


18% 


TCH-P8/10,8 


BER 


1 ,6 % 


4,5 % 


1 ,4 % 


1 ,6 % 


3,7 % 
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6.6.2.3.2 



MS receiver performance 



Table 6.36 gives the maximum permissible receiver MER or BER at reference interference with 7t/4-DQPSK 
modulation. 

Table 6.36: Maximum permissible MS receiver MER or BER at reference interference level 







Continuous downlink mode 


Discontinuous downlink 
mode 


Propagation 
condition 


Logical channel 


Error 
count 
type 


Propagation condition 


Propagation condition 


TU50 


HT200 


EQ200 


TU50 


HT200 


TU50 


Class A, E 


Class A 


Class E 


Class A 


Class A 


Class B 


AACH 


MER 


9% 


16% 


14% 


9% 


16% 


9% 


BSCH 


MER 


6% 


10% 


20% 


6% 


10% 


6% 


SCH/HD 


MER 


7% 


9,2 % 


20% 


7% 


9,2 % 


7% 


BNCH 


MER 


7% 


9,2 % 


20% 


7% 


9,2 % 


7% 


SCH/F 


MER 


6,5 % 


9,2 % 


20% 


6,5 % 


7,5 % 


6,5 % 


TCH/7,2 


BER 


2% 


3,8 % 


4,2 % 


2% 


3,8 % 


2% 


TCH/4,8 N= 1 


BER 


2% 


4% 


6,2 % 


4% 


4% 


2% 


TCH/4,8 N = 4 


BER 


0,4 % 


3,3 % 


2,5 % 


1 ,2 % 


4% 


0,4 % 


TCH/4,8 N = 8 


BER 


0,06 % 


3% 


1 ,2 % 


0,4 % 


4% 


0,06 % 


TCH/2,4 N = 1 


BER 


0,35 % 


1,1 % 


0,84 % 


1 ,2 % 


1 ,3 % 


0,35 % 


TCH/2,4 N = 4 


BER 


0,01 % 


0,4 % 


0,01 % 


0,02 % 


0,4 % 


0,01 % 


TCH/2,4 N = 8 


BER 


0,01 % 


0,13% 


0,01 % 


0,01 % 


0,2 % 


0,01 % 


STCH 


MER 


7% 


9,2 % 


20% 


7% 


9,2 % 


7% 


NOTE 1 : N gives the interleaving deptli in number of blocks (see clause 8). 

NOTE 2: Class B receiver performance are for both Continuous and Discontinuous downlink mode. 



Table 6.37 gives the maximum permissible receiver MER or BER at reference interference with 7t/8-D8PSK 
modulation. 

Table 6.37: Maximum permissible MS receiver MER or BER 
at reference interference level with 71/8-D8PSK modulation 







Continuous downlink mode 


Discontinuous downlink mode 


Propagatio 
n condition 


Logical 
channel 


Error 
coun 
ttype 


Propagation condition 


Propa 


gation condition 


TU50 


HT200 


HT200 


TU50 


HT200 


HT200 


TU50 


Class A, 
D 


Class A 


Class 
D 


Class A, D 


Class A 


Class D 


Class B 


SCH-P8/HD 


MER 


7,6 % 


21 % 


16% 


7,9 % 


21 % 


15% 


6,6 % 


SCH-P8/F 


MER 


10% 


29% 


19% 


19% 


29% 


18% 


8,9 % 


TCH-P8/10,8 


BER 


1 ,6 % 


4,5 % 


3,5 % 


3,5 % 


4,5 % 


3,6 % 


1 ,4 % 


NOTE 1 : N gives the interleaving depth in number of blocks (see clause 8). 

NOTE 2: Class B receiver performance are for both Continuous and Discontinuous downlink mode. 



6.6.2.4 Static reference sensitivity performance for phase modulation 

The minimum required static reference sensitivity performance is specified according to the logical channel and the 
receiver class at the static reference sensitivity level. The static reference sensitivity level shall be: 

• for MS 7t/4-DQPSK modulation: -112 dBm; 

• for MS rt/8-D8PSK modulation: -107 dBm; 

• for BS 7t/4-DQPSK modulation: -1 15 dBm; 

• for BS 7t/8-D8PSK modulation: -1 10 dBm. 

Tables 6.38 and 6.40 give the minimum required reference sensitivity performance for 7t/4-DQPSK. For BSCH, 
SCH/HD, SCH/HU, SCH/F, BNCH, a PUEM < 0,001 % shall be achieved at the static reference sensitivity level. For 
AACH a PUEM < 0,01 % shall be achieved at the static reference sensitivity level. 
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Tables 6.39 and 6.41 give the minimum required reference sensitivity performance for 71/8-D8PSK. For SCH-P8/HD, 
SCH-P8/HU, SCH-P8/F, a PUEM < 0,001% shall be achieved at the static reference sensitivity level. 

6.6.2.4.1 BS receiver performance 

Table 6.38 gives the minimum required reference sensitivity performance for 7t/4-DQPSK. 

Table 6.38: Maximum permissible BS receiver MER or BER 
at static reference sensitivity level with 71/4-DQPSK modulation 



Logical channel 


Error count type 


Class A 


Class B 


SCH/HU 


MER 


3% 


3% 


SCH/F 


MER 


10% 


10% 


TCH/7,2 


BER 


3% 


4% 


TCH/4,8 N = 1 


BER 


3,3 % 


0,3 % 


TCH/4,8 N = 4 


BER 


1 % 


0,2 % 


TCH/4,8 N = 8 


BER 


0,4 % 


0,2 % 


TCH/2,4 N = 1 


BER 


0,2 % 


0,01 % 


TCH/2,4 N = 4 


BER 


0,01 % 


0,01 % 


TCH/2,4 N = 8 


BER 


0,01 % 


0,01 % 


STCH 


MER 


8% 


5% 


NOTE: N gives the interleaving depth in number of blocl<s (see clause 8). 



Table 6.39 gives the minimum required reference sensitivity performance for 7t/8-D8PSK. 

Table 6.39: Maximum permissible BS receiver MER or BER 
at static reference sensitivity level with 71/8-D8PSK modulation 



Logical channel 


Error count type 


Class A, D 


Class B 


SCH-P8/HU 


MER 


4,5 % 


4,3 % 


SCH-P8/F 


MER 


9,3 % 


9,3 % 


TCH-P8/10,8 


BER 


3,8 % 


3,1 % 



6.6.2.4.2 MS receiver performance 

Table 6.40 gives the minimum required reference sensitivity performance for 7t/4-DQPSK. 

Table 6.40: Maximum permissible MS receiver MER or BER at static reference sensitivity level 



Logical channel 


Error 
count 
type 


Continuous 
downlink mode 


Discontinuous 
downlink mode 


Class B 


Class A,E 


Class A 


AACH 


MER 


28% 


28% 


38% 


BSCH 


MER 


3% 


3% 


3% 


SCH/HD 


MER 


2,5 % 


8% 


5% 


BNCH 


MER 


2,5 % 


8% 


5% 


SCH/F 


MER 


4,5 % 


9% 


9% 


TCH/7,2 


BER 


3,5 % 


3,5 % 


4% 


TCH/4,8 N = 1 


BER 


0,3 % 


2% 


0,3 % 


TCH/4,8 N = 4 


BER 


0,2 % 


0,8 % 


0,2 % 


TCH/4,8 N = 8 


BER 


0,15% 


0,4 % 


0,15% 


TCH/2,4 N = 1 


BER 


0,01 % 


0,01 % 


0,01 % 


TCH/2,4 N = 4 


BER 


0,01 % 


0,01 % 


0,01 % 


TCH/2,4 N = 8 


BER 


0,01 % 


0,01 % 


0,01 % 


STCH 


MER 


2,5 % 


8% 


5% 


NOTE 1 : N gives th( 
NOTE 2: Class B re 
mode. 


3 interleaving depth in number of blocks (see clause { 
ceiver performance are for both Continuous and Disc 


3). 

ontinuous downlink 
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Table 6.41 gives the minimum required reference sensitivity performance for 7t/8-D8PSK. 

Table 6.41 : Maximum permissible MS receiver MER or BER 
at static reference sensitivity level with 71/8-D8PSK modulation 



Logical channel 


Error 
count 
type 


Continuous 
downlink mode 


Discontinuous 
downlink mode 




Class A, D 


Class A, D 


Class B 


SCH-P8/HD 


MER 


5,6 % 


5,6 % 


1 ,6 % 


SCH-P8/F 


MER 


10% 


10% 


9,3 % 


TCH-P8/10,8 


BER 


3,9 % 


3,9 % 


3,2 % 


NOTE: Class B receiver performance are for both Continuous and Discontinuous downlink 
modes. 



6.6.2.5 



MS receiver performance for synchronization burst acquisition 



This clause specifies reference sensitivity performance of a MS receiver for the acquisition of the Synchronization (sub) 
Burst (SB), refer to table 6.42. The performance is defined in terms of the probability PACQ of detecting a single 
transmitted SB and correctly decoding its BSCH information for the condition where the MS is listening on the 
frequency while the SB is transmitted and where the MS is already frequency synchronized but not synchronized in 
terms of time slots. 

Table 6.42: MS receiver performance for synchronization burst acquisition 



Propagation condltlon/eq. class 


TU50/class B 


HT200/class A, E 


PACQ 


0,8 


0,8 


NOTE: This specification applies for continuous and discontinuous downlink mode. 



6.7 Transmitter/receiver performance for QAM 

Clause 6.7.1 specifies the modulation accuracy requirement, by setting limits on the Root Mean Square (RMS) error 
between the actual transmitted signal waveform and the ideal signal waveform. Clause 6.7.2 specifies the receiver 
performance, assuming that transmit errors do not occur. Clause 6.8 specifies all the propagation models that are 
defined in the present document. 

6.7.1 Transmitter performance for QAM 



6.7.1.1 



Modulation accuracy for QAM 



The specified requirement is vector error magnitude; this does not only take into account modulation filtering linear 
distortion (amplitude and phase) or modulator impairments (quadrature offset, phase and linear amplitude errors in the 
modulation symbol constellation) but is a measure of the whole transmitter quality. It also takes into account local 
oscillator phase noise, filter distortion, non-linearity of amplifiers and overlap of sub_carriers. Vector error magnitude 
shall be specified at symbol time (see clause 6.7.1.2) and the vector error magnitude requirement shall be fulfilled by 
the TETRA QAM equipment over all sub-carriers within the channel bandwidth with maximum and with minimum 
power levels (as defined in clause 6.4.8). 

The modulation symbol sjt) transmitted on an individual sub-carrier m by an ideal transmitter having a filter impulse 
response g(t) is defined in clause 5.16. 

Let ZJk) denote the output of an ideal sub-carrier receive filter with impulse response: 



9'(-')|,=,. 



(6.10) 
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The ideal sub-carrier transmit and receive filters in cascade form a raised cosine Nyquist filter, having a sub-carrier 
symbol waveform going through zero at symbol duration intervals, so there is no inter-symbol interference at any 
instant t = t/^, where t), is the symbol time corresponding to the A:-th symbol (as defined in clause 5.16). In the frequency 
domain, the ideal sub-carrier transmit and receive filters have a bandwidth slightly greater than the sub-carrier spacing, 
so there is some sub-carrier overlap and limited inter-sub-carrier-symbol interference. 

In this case, the output of an ideal sub-carrier receive filter at any instant f^, stimulated by an ideal transmitter, will be 
equal to the A;-th modulation symbol S,„(k) for the associated sub-carrier SC„r. 

Z^ik)=s„{t)*g'i-tl__,^ =S,M+i,n(k) (6.11) 

where I„(k) is the inter-sub-carrier-symbol interference. 

In this clause, the numbering of the modulation symbols used is the one defined in clause 9 for QAM. 

6.7.1 .2 Vector error magnitude requirement at symbol time for QAM 

Let ZJk) for an individual sub-carrier m be the output produced by observing the real transmitter through the ideal sub- 
carrier receive filter at symbol time t/,. ZJk) is modelled as: 

Z^{k) = {S„{k)+E,„{k)]CJV{k) (6.12) 

Where: 

• E,„(k) is the vector error of modulation symbol SJk) on sub-carrier m; 

• W(k) accounts for phase and amplitude variations common to all sub-carriers as a function of symbol number 
k; 

• Cm is a complex constant representing the output amplitude and initial phase of the transmitter, characterized 
for the initial sync symbols on the m-th sub-carrier 

The task of the test receiver is then to: 

• estimate the symbol time for processing the receive part; 

• estimate the values of C^ from all sync and pilot symbols on each sub-carrier m; 

• estimate the values of W(k) as a best fit for all pilot symbols in the burst; 

• estimate the values of W(k) across the burst in time by interpolation. The resulting estimates shall be denoted 
by W'(k) respectively; 

• perform a normalization of the modulation symbol Z„(k) accordingly. The modulation symbol that results from 
this normalization shall be denoted by Z^Jk): 



z:{k)=[zM/(cy{k)) 

With the above notations, the Sum Square Vector Error (SSVE) is defined as: 

ssvE = Y,J]zAk)-sM 



(6.13) 



M-ISN„_ 

(6.14) 



m=0 k=l 

where SN^ax is the number of symbols per sub-carrier in the burst and M is the number of sub-carriers. S,„(k) includes 
pilot and sync sub-carrier symbols. 

The RMS vector error across all sub-carriers is then computed as the square root of the sum-square vector error divided 
by the total number of sub-carrier symbols in the burst including pilot and sync sub-carrier symbols: 



RMSVE = ^SSVE/{MxSN,^^J (6.15) 
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The RMS vector error in any burst shall be less than 0,1. 
Additional tasks of the test receiver are to: 

• Calculate 0(k), the difference in phase of W'(k) between successive symbols: 

0{k)=arg{W'{k))-arg{W'{k + l)) fork= 1 to (5A?„^- 1) (6.16) 

• Calculate the mean frequency error df^ea,, over the burst: 

C.«„ = V(2^-(^A^,na. -1)) Z^ik) (6.17) 

k=l 

where: 

dfmean IS exprcsscd in Hz and T is the symbol duration in s; 

• Calculate the peak frequency error dfpeak over the burst: 

4fpeak - y{2^)0{k ) for the greatest absolute value of 0{k ) (6.18) 

NOTE: In the present clause identifier "SN^" is used instead of "SNmax" used elsewhere. 

6.7.2 Receiver performance for QAM 

This clause specifies the minimum required receiver performance in terms of Bit Error Ratio (BER), Message Erasure 
Rate (MER) or Probability of Undetected Erroneous Message (PUEM) (whichever is appropriate), taking into account 
that transmitter errors do not occur, and that the transmitter shall be tested separately (see clause 6.7.1). 

In this clause, the levels of the test signals are given in terms of power levels (dBm) at the antenna connector of the 
receiver. For the definition of power level refer to clause 6.4.8. 

6.7.2.1 Nominal error rates for QAM 

For SCH-Q/RA, SCH-Q/HU, SCH-Q/U, SCH-Q/D, and BNCH-Q a PUEM < lO'^ shall be achieved at the dynamic 
reference sensitivity level. For AACH-Q, a PUEM < 5 x lO"'* shall be achieved at the dynamic reference sensitivity 
levels. 

For QAM the nominal error rates for non-protected bits are outside the scope of the present document. 

6.7.2.2 Dynamic reference sensitivity performance for QAM 

The minimum required dynamic reference sensitivity performance is specified according to the logical channel, the 
propagation condition, coding rate, modulation and channel bandwidth. 

Tables 6.43, 6.44 and 6.45 specify dynamic reference sensitivity for frequencies below 700 MHz for 4-QAM, 16-QAM 
and 64-QAM respectively. 

Table 6.46 specifies the maximum permissible receiver MER for frequencies below 700 MHz at dynamic reference 
sensitivities specified in tables 6.43, 6.44 and 6.45. 

Tables 6.47, 6.48 and 6.49 specify dynamic reference sensitivity for frequencies above 700 MHz for 4-QAM, 16-QAM 
and 64-QAM respectively. 

Table 6.50 specifies the maximum permissible receiver MER for frequencies above 700 MHz at dynamic reference 
sensitivities specified in tables 6.47, 6.48 and 6.49. 
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Table 6.43: 4-QAM BS and MS dynamic reference sensitivity for frequencies below 700 IVIHz 



Channel BW 


BS, r = 1/2 


MS, r = 1/2 


25 kHz 


-111 dBm 


-108 dBm 


50 kHz 


-108 dBm 


-105 dBm 


100 kHz 


-105 dBm 


-102 dBm 


150 kHz 


-104 dBm 


-101 dBm 



Table 6.44: 16-QAI\/I BS and MS dynamic reference sensitivity for frequencies below 700 MHz 



Channel BW 


BS, r = 1/2 


MS, r = 1/2 


25 kHz 


-106 dBm 


-103 dBm 


50 kHz 


-102 dBm 


-100 dBm 


100 kHz 


-100 dBm 


-97 dBm 


150 kHz 


-99 dBm 


-96 dBm 



Table 6.45: 64-QAM BS and MS dynamic reference sensitivity for frequencies below 700 MHz 



Channel BW 


BS, r = 1/2 


BS, r = 2/3 


MS, r = 1/2 


MS, r = 2/3 


25 kHz 


-101 dBm 


-98 dBm 


-98 dBm 


-95 dBm 


50 kHz 


-98 dBm 


-94 dBm 


-95 dBm 


-91 dBm 


100 kHz 


-95 dBm 


-92 dBm 


-92 dBm 


-88 dBm 


150 kHz 


-94 dBm 


-91 dBm 


-91 dBm 


-87 dBm 



Table 6.46: Maximum permissible MS and BS receiver MER 
at dynamic reference sensitivity level for frequencies below 700 MHz 



Type of 
channel 


Payload 
modulation 


BS/MS 


Code 
rate 


25 kHz 


50 kHz 


100 kHz 


150 kHz 1 


TU50 


HT200 


TU50 


HT200 


TU50 


HT200 


TU50 


HT200 


SCH-Q/RA 


4-QAM 


BS 


1/2 


11,1 % 


7,4 % 


- 


- 


- 


- 


- 


- 


SICH-Q/U 
inCB 


4-QAM 


BS 


1/2 


5,5 % 


1 ,8 % 


3,6 % 


1 ,6 % 


3,8 % 


1 ,2 % 


5,3 % 


2,0 % 


SCH-Q/HU 


4-QAM 


BS 


1/2 


11 % 


7,7 % 


9,3 % 


5,6 % 


9,0 % 


3,3 % 


12,9% 


7,6 % 


SICH-Q/U 
in NUB 


4-QAM 


BS 


1/2 


3,6 % 


1 ,4 % 


3,5 % 


1 ,3 % 


3,6 % 


1,1 % 


3,9 % 


1 ,6 % 


SCH-Q/U 


4-QAM 


BS 


1/2 


8,3 % 


3,7 % 


9,4 % 


2,0 % 


9,0 % 


1 ,5 % 


8,1 % 


3,2 % 


SICH-Q/D 


4-QAM 


MS 


1/2 


1 ,9 % 


0,8 % 


2,1 % 


0,9 % 


2,1 % 


0,9 % 


2,3 % 


0,9 % 


AACH-Q 


4-QAM 


MS 


1/2 


5,8 % 


2,5 % 


6,2 % 


2,7 % 


6,2 % 


2,8 % 


6,8 % 


2,8 % 


BNCH-Q, 
SCH-Q/D 


4-QAM 


MS 


1/2 


7,8 % 


2,3 % 


10% 


1 ,8 % 


8,7 % 


1 ,8 % 


8,4 % 


1 ,8 % 


SCH-Q/HU 


1 6-QAM 


BS 


1/2 


1 1 ,9 % 


8,2 % 


7,9 % 


3,6 % 


9,9 % 


3,5 % 


13,2% 


7,5 % 


SCH-Q/U 


1 6-QAM 


BS 


1/2 


8,8 % 


3,9 % 


7,0 % 


1,1 % 


9,5 % 


1 ,6 % 


8,9 % 


3,5 % 


BNCH-Q, 
SCH-Q/D 


1 6-QAM 


MS 


1/2 


8,6 % 


2,9 % 


7,2 % 


1 ,0 % 


9,0 % 


1 ,9 % 


8,7 % 


1 ,8 % 


SCH-Q/HU 


64-QAM 


BS 


1/2 


11 % 


7,0 % 


8,9 % 


4,8 % 


8,7 % 


3,0 % 


12,1 % 


6,2 % 


SCH-Q/U 


64-QAM 


BS 


1/2 


7,8 % 


3,7 % 


9,9 % 


3,0 % 


7,7 % 


1 ,6 % 


6,9 % 


2,7 % 


BNCH-Q, 
SCH-Q/D 


64-QAM 


MS 


1/2 


7,4 % 


2,6 % 


9,3 % 


1 ,9 % 


7,3 % 


1 ,8 % 


7,4 % 


1 ,6 % 


SCH-Q/HU 


64-QAM 


BS 


2/3 


1 1 ,2 % 


1 1 ,2 % 


7,8 % 


7,6 % 


9,9 % 


7,1 % 


14,1 % 


1 1 ,8 % 


SCH-Q/U 


64-QAM 


BS 


2/3 


9,5 % 


7,7 % 


8,3 % 


4,4 % 


9,6 % 


5,1 % 


9,3 % 


8,1 % 


BNCH-Q, 
SCH-Q/D 


64-QAM 


MS 


2/3 


9,3 % 


6,2 % 


8,1 % 


3,0 % 


7,3 % 


3,6 % 


6,9 % 


3,9 % 
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Table 6.47: 4-QAM BS and MS dynamic reference sensitivity for frequencies above 700 IVUHz 



Channel BW 


BS, r = 1/2 


MS, r = 1/2 


25 kHz 


-111 dBm 


-108 dBm 


50 kHz 


-108 dBm 


-105 dBm 


100 kHz 


-105 dBm 


-102 dBm 


150 kHz 


-104 dBm 


-101 dBm 



Table 6.48: 16-QAI\/I BS and MS dynamic reference sensitivity for frequencies above 700 MHz 



Channel BW 


BS, r = 1/2 


MS, r = 1/2 


25 kHz 


-107 dBm 


-103 dBm 


50 kHz 


-103 dBm 


-100 dBm 


100 kHz 


-100 dBm 


-97 dBm 


150 kHz 


-99 dBm 


-96 dBm 



Table 6.49: 64-QAM BS and MS dynamic reference sensitivity for frequencies above 700 MHz 



Channel BW 


BS, r = 1/2 


BS, r = 2/3 


MS, r = 1/2 


MS, r = 2/3 


25 kHz 


-102 dBm 


-98 dBm 


-99 dBm 


-95 dBm 


50 kHz 


-98 dBm 


-94 dBm 


-95 dBm 


-91 dBm 


100 kHz 


-96 dBm 


-92 dBm 


-93 dBm 


-89 dBm 


150 kHz 


-94 dBm 


-90 dBm 


-92 dBm 


-88 dBm 



Table 6.50: Maximum permissible MS and BS receiver MER 
at dynamic reference sensitivity level for frequencies above 700 MHz 











25 kHz 


50 kHz 


100 kHz 


150 kHz 1 


Type of 
channel 


Payload 

modulatio 

n 


BS/MS 


Code 
rate 


TU50 


HT200 


TU50 


HT200 


TU50 


HT200 


TU50 


HT200 


SCH-Q/RA 


4-QAM 


BS 


1/2 


14,2% 


5,9 % 


- 


- 


- 


- 


- 


- 


SICH-Q/U 
inCB 


4-QAM 


BS 


1/2 


4,6 % 


1 ,0 % 


5,3 % 


1,1 % 


3,0 % 


1 ,2 % 


4,2 % 


1 ,4 % 


SCH-Q/HU 


4-QAM 


BS 


1/2 


14,3% 


5,5 % 


14,2% 


4,4 % 


1 0,3 % 


3,5 % 


13,4% 


5,2 % 


SICH-Q/U 
in NUB 


4-QAM 


BS 


1/2 


2,6 % 


1 ,0 % 


3,2 % 


0,9 % 


1 ,2 % 


1 ,0 % 


3,7 % 


1 ,4 % 


SCH-Q/U 


4-QAM 


BS 


1/2 


7,0 % 


2,0 % 


8,5 % 


1,1 % 


6,8 % 


0,9 % 


9,1 % 


1 ,6 % 


SICH-Q/D 


4-QAM 


MS 


1/2 


1 ,4 % 


0,7 % 


1 ,9 % 


0,7 % 


1 ,7 % 


0,6 % 


2,1 % 


1 ,0 % 


AACH-Q 


4-QAM 


MS 


1/2 


4,2 % 


2,2 % 


5,7 % 


2,0 % 


5,0 % 


1 ,9 % 


6,3 % 


3,1 % 


BNCH-Q, 
SCH-Q/D 


4-QAM 


MS 


1/2 


7,6 % 


1,7% 


10% 


0,8 % 


7,4 % 


0,6 % 


7,6 % 


1 ,4 % 


SCH-Q/HU 


16-QAM 


BS 


1/2 


1 6,5 % 


1 0,8 % 


14,2% 


4,8 % 


11,1 % 


4,1 % 


13,4% 


5,2 % 


SCH-Q/U 


16-QAM 


BS 


1/2 


9,0 % 


5,7 % 


8,6 % 


1 ,4 % 


6,3 % 


1,1 % 


8,9 % 


2,5 % 


BNCH-Q, 
SCH-Q/D 


16-QAM 


MS 


1/2 


7,2 % 


2,1 % 


8,4 % 


0,9 % 


7,2 % 


0,9 % 


7,5 % 


1 ,7 % 


SCH-Q/HU 


64-QAM 


BS 


1/2 


16% 


11 % 


13% 


5,7 % 


12,2% 


8,4 % 


1 1 ,3 % 


5,0 % 


SCH-Q/U 


64-QAM 


BS 


1/2 


7,5 % 


6,7 % 


10% 


4,8 % 


8,3 % 


4,4 % 


6,5 % 


2,9 % 


BNCH-Q, 
SCH-Q/D 


64-QAM 


MS 


1/2 


9,4 % 


5,6 % 


7,0 % 


1 ,8 % 


8,1 % 


2,7 % 


8,9 % 


6,0 % 


SCH-Q/HU 


64-QAM 


BS 


2/3 


1 5,4 % 


1 6,6 % 


12,9% 


13,2% 


1 1 ,7 % 


16% 


10,9% 


12,1 % 


SCH-Q/U 


64-QAM 


BS 


2/3 


8,0 % 


16,6% 


7,8 % 


1 2,5 % 


7,7 % 


14% 


7,2 % 


15,3% 


BNCH-Q, 
SCH-Q/D 


64-QAM 


MS 


2/3 


9,2 % 


18,6% 


7,1 % 


7,9 % 


8,7 % 


1 1 ,9 % 


9,1 % 


20,7 % 
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6.7.2.3 



Receiver performance at reference interference ratios for QAM 



6.7.2.3.1 



Adjacent channel interference 



The minimum required reference adjacent channel interference performance is specified in table 6.51 according to the 
wanted signal channel bandwidth. 

Table 6.51 : Adjacent channel interferer frequency offsets and mean power levels for QAM 



QAM Channel 
bandwidth 


TETRA 7t/4-DQPSK 
Interferer offset from f^ 


TETRA 7t/4-DQPSK 
Interferer level for MS 


TETRA it/4-DQPSK 
Interferer level for BS 


25 kHz 


25 kHz 


-63 dBm 


-62 dBm 


50 kHz 


37,5 kHz 


-66 dBm 


-66 dBm 


100 kHz 


62,5 kHz 


-70 dBm 


-70 dBm 


150 kHz 


87,5 kHz 


-70 dBm 


-70 dBm 



The static reference sensitivity performance as specified in clause 6.7.2.4 shall be met when the following signals are 
simultaneously input to the receiver: 

• a wanted signal at the nominal receive frequency Z^, 3 dB above the static reference sensitivity level as 
specified in clause 6.7.2.4; and 

• a TETRA 7t/4-DQPSK random modulated continuous signal at a frequency offset from/^ and level as defined 
in table 6.51. 



6.7.2.3.2 



Co-channel interference 



The minimum required reference co-channel interference performance is specified according to channel bandwidth, 
modulation, coding rate and propagation conditions. For BS co-channel interference ratio is defined for SCH-Q/U 
logical channel. For MS co-channel interference ratio is defined for SCH-Q/D logical channel. Co-channel interference 
specifications apply for a wanted input signal level of 25 dB above dynamic reference sensitivity (as specified in 
tables 6.47, 6.48, 6.49, 6.43, 6.44 and 6.45. 

Table 6.52 defines co-channel interference ratios C/Ic, for frequencies below 700 MHz. Table 6.53 defines co-channel 
interference ratios C/Ic, for frequencies above 700 MHz. The maximum permissible MER for reference co-channel 
interference ratios is 10 %. 

Table 6.52: BS and MS minimum dynamic reference interference ratio (C/lc for 10 % MER) 

for frequencies below 700 MHz 



Modulation 


r = 1/2 
TU50 


r = 1/2 
HT200 


r = 2/3 
TU50 


r = 2/3 
HT200 


4-QAM 


14dB 


12dB 


- 


- 


16-QAM 


19dB 


17dB 


- 


- 


64-QAM 


23 dB 


22 dB 


27dB 


26 dB 



Table 6.53: BS and MS minimum dynamic reference interference ratio (C/lc for 10 % MER) 

for frequencies above 700 MHz 



Modulation 


r = 1/2 
TU50 


r = 1/2 
HT200 


r = 2/3 
TU50 


r = 2/3 
HT200 


4-QAM 


14dB 


12dB 


- 


- 


16-QAM 


19dB 


17dB 


- 


- 


64-QAM 


24 dB 


23 dB 


27dB 


29 dB 
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6.7.2.4 static reference sensitivity performance for QAM 

The minimum required static reference sensitivity performance for MS is specified in table 6.54. 

Table 6.54: QAM Sensitivity levels for MS 



Channel BW 


4-QAM 3 % 
BER Sensitivity 


16-QAM3% 
BER Sensitivity 


64-QAM 3 % 
BER Sensitivity 


25 kHz 


-113dBm 


-106 dBm 


-101 dBm 


50 kHz 


-110dBm 


-103 dBm 


-97 dBm 


100 kHz 


-107 dBm 


-100 dBm 


-95 dBm 


150 kHz 


-105 dBm 


-99 dBm 


-93 dBm 



The minimum required static reference sensitivity performance for BS is specified in table 6.55. 

Table 6.55: QAM Sensitivity levels for BS 



Channel BW 


4-QAIVI 3 % 
BER Sensitivity 


16-QAM3% 
BER Sensitivity 


64-QAIVI 3 % 
BER Sensitivity 


25 kHz 


-116dBm 


-109 dBm 


-104 dBm 


50 kHz 


-IISdBm 


-106 dBm 


-100 dBm 


100 kHz 


-IIOdBm 


-103 dBm 


-98 dBm 


150 kHz 


-108 dBm 


-102 dBm 


-96 dBm 



6.8 Propagation conditions 



The following clauses contain all necessary information on the propagation models that are referred to in the present 
document. 

6.8.1 Propagation conditions - introduction 

Radio wave propagation in the mobile radio environment is described by dispersive multipath caused by reflection, 
diffraction and scattering. Different paths may exist between a BS and a MS due to large distant reflectors and/or 
scatterers and due to scattering in the vicinity of the mobile, giving rise to a number of partial waves arriving with 
different amplitudes and delays. Since the mobile will be moving, a Doppler shift is associated with each partial wave, 
depending on the mobile's velocity and the angle of incidence. The delayed and Doppler shifted partial waves interfere 
at the receiver causing frequency and time selective fading on the transmitted signal. 

When system bandwidth and propagation path lengths are sufficiently small (which is the case for TETRA), the 
resulting frequency and time selective fading process may be simulated by a simplified propagation model. Such a 
model exhibits only a few discrete paths which are independently fading. For practical channel simulation, stationary 
Gaussian processes with a power density spectrum equal to the classical Doppler spectrum are commonly assumed. 

Based on extensive investigations (Digital Land Mobile Radiocommunications, M. Failli (Ed.), 
Final Report 14.3.1984-13.9.1988, published by European Commission, Directorate of General Telecommunication, 
Information Industries and Innovation. Luxembourg. ISBN 92-825-9946-9. (1989)) some tapped delay line models 
which are typical for urban, rural, or hilly area propagation conditions or for quasi-synchronous operation were derived. 
These models are defined in the following terms (see also table 6.56): 

• number of discrete taps; 

• relative delay of each tap; 

• average relative power of the complex tap-gain process of each tap; 

• type of the complex tap-gain process of each tap. 

All stochastic tap-gain processes are mutually statistically independent. 
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6.8.2 Tap-gain process types 



This clause defines the statistical properties of the stationary complex tap-gain processes, to be applied for the 
propagation models, in terms of a Probability Density Function (PDF) and a Power Density Spectrum (PDS) which 
models the Doppler spectrum. The complex tap-gain processes, denoted by a(t) and defined hereunder, are normalized 
to unity power. 

CLASS is the tap-gain process having a PDS equal to the classical Doppler spectrum. The real and imaginary parts of 
a(t) exhibit an identical Gaussian PDF, an identical PDS and are mutually statistically independent. Hence \a(t)\ is 
Rayleigh distributed. The PDS of a(t) is defined by: 



S{f) = Scu^ss{fJ,)= ^ 



^d^1-{f/f/ 



S{f) = 



for -fd<f<fd; and 



elsewhere (6.19) 



Where the parameter/^ represents the maximum Doppler shift (in Hz), defined as/^ = v/A. with the vehicle speed v 
(in m/s) and the wavelength A. (in m). 

STATIC(fs) is a tap-gain process with a constant magnitude \a(t)\= 1 . The PDS ofa(t) is defined by: 

m = SsTATIc[f Js) = S[f - Q (6.20) 

Where d(.) represents the Dirac delta function and/^ the Doppler shift (in Hz). 

RICE is a tap-gain process which is the sum process of the two processes CLASS and STATIC(fs), with/^ = 0, 7/^, each 
contributing half of the total power. Hence \a(t)\ is Rician distributed and the PDS is: 

S(0 = Sf,CE{f, f,) = O^ScLAssif. Q + O^SsTATIc[f, 0,7f,) (g 21) 
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6.8.3 Propagation models 



In this clause, the propagation models that are referred to in the present document are defined. For Phase modulation 
three models are used TU50, HT200 and EQ200, refer to table 6.56. For QAM two models are used: TU50 and HT200 
refer to table 6.57. For Phase modulation the vehicle speed x (in km/h), which affects fd (see clause 6.8.2), is attributed 
to the model designation in the frequency range 380 MHz to 520 MHz (e.g. HT200 means Hilly Terrain for 200 km/h in 
the 380 MHz to 520 MHz frequency range). 

For Phase Modulation to keep the Doppler shift constant relative to 430 MHz, for frequencies outside the 380 MHz to 
520 MHz range, for testing purposes only, the vehicle speed in the model is adjusted according the formula: 

• V = 20 [Hz] X >. [m], when TU50 is specified; 

• V = 80 [Hz] xX[m], when HT200 and EQ200 are specified. 
NOTE: X = V X 3,6. 

Table 6.56: Propagation models for Phase Modulation 



Propagation model 


Tap number 


Relative delay (^s) 


Average relative 
power (dB) 


Tap-gain 
process 


Static 


1 








STATIC(O) 


Rural Area (RAx) 


1 








RICE 


Typical Urban (TUx) 


1 








CLASS 


2 


5 


-22,3 


CLASS 


Bad Urban (BUx) 


1 








CLASS 


2 


5 


-3,0 


CLASS 


Hilly Terrain (HTx) 


1 








CLASS 


2 


15 


-8,6 


CLASS 


Equalizer Test (EQx) 


1 








CLASS 


2 


11,6 





CLASS 


3 


73,2 


-10,2 


CLASS 


4 


99,3 


-16 


CLASS 



Table 6.57: Propagation models for QAM 



Propagation model 


Tap number 


Relative delay (|is) 


Average relative 
power (dB) 


Tap-gain 
process 


Typical Urban (TUx) 


1 


0,0 


-3,0 


CLASS 


2 


0,2 


0,0 


CLASS 


3 


0,6 


-2,0 


CLASS 


4 


1,6 


-6,0 


CLASS 


5 


2,4 


-8,0 


CLASS 


6 


5,0 


-10,0 


CLASS 


Hilly Terrain (HTx) 


1 


0,0 


0,0 


CLASS 


2 


0,2 


-2,0 


CLASS 


3 


0,4 


-4,0 


CLASS 


4 


0,6 


-7,0 


CLASS 


5 


15,0 


-6,0 


CLASS 


6 


17,2 


-12,0 


CLASS 
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7 Radio sub-system synchronization 

7.1 Introduction 

Clauses 7.2 to 7.8 define the requirements for synchronization on the TETRA V+D radio sub-system, for carrier 
frequencies of between 300 MHz and 1 GHz. It does not define the synchronization algorithms to be used in the BS and 
MS. These are up to the manufacturer to specify. 

7.2 General description of synchronization system 

This clause gives a general description of the synchronization system. Detailed requirements are given in the subsequent 
clauses. 

The BS sends signals on the BSCH to enable the MS to synchronize itself to the BS and if necessary correct its 
frequency standard to be in line with that of the BS. The signals sent by the BS for these purposes are frequency 
correction signals and synchronization signals. 

The timings of timeslots, TDMA frames and multiframes are all related to a common set of counters which run 
continuously whether the MS and BS are transmitting or not (see clauses 7.3 and 7.5). Thus, once the MS has 
determined the correct setting of these counters, all its processes are synchronized to the current serving BS. 

The MS has to time its transmissions to the BS in line with those received from the BS. This process is called "mobile 
timebase adjustment". 

7.3 Timebase counters for phase modulation 

7.3.1 Timing counters for phase modulation 

The timing state of the signals transmitted by a BS or MS shall be defined by the following counters: 

• Symbol Number (SN)(1 - 255); 

• Timeslot Number (TN)(1 - 4); 

• TDMA Frame Number (FN)(1 - 18); 

• TDMA Multiframe Number (MN)(1 - 60). 

NOTE: SNO indicates the last symbol of the previous timeslot, i.e. SNO is equals SN255 of the previous timeslot. 

7.3.2 Values of the counters for phase modulation 

The relationship between these counters shall be as follows: 

• SN increments every 500/9 |is (for an MS, this holds unless otherwise required by the mobile timebase 
adjustment); 

• TN increments at the beginning of each timeslot (at symbol time of SNO of the downlink for a continuous 
downlink transmission); 

• FN increments whenever TN changes from count 4 to 1 ; 

• AW increments whenever /W changes from 18 to 1. 

The simultaneous change of state of all counters to 1 defines the timebase reference. This timebase reference takes into 
account the offset required in the case of MCCH sharing (+18 frames). 
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7.4 Timing of transmitted signals for phase modulation 

The timing of modulation symbols transmitted by the MS and BS is defined in clause 9. 

The MS may use the timing of receipt of the synchronization burst to set-up its timebase counters. If it does, it shall do 
so as follows: 

• the value of 77V shall be read from the BSCH, when received. In any other case, augmentation of 77V shall be 
given by: 

TA^: = TA^ mod (4) + 1 (7.1) 

• the value of FN shall be read from the BSCH, when received. In any other case, augmentation of FN shall be 
given by: 

FN = FN mod ( 1 8) + 1 (7.2) 

• the value of MN is read from the BSCH, when received. In any other case, augmentation of MN shall be given 
by: 

MN. = MN mod (60) + 1 (7.3) 

When BSs that differ from the current serving BS are being monitored for call re-establishment or handover purposes, 
the MS may choose to store the values of TN, FN and MN for all the BSs whose synchronization bursts have been 
detected relative to TN, FN and MN for its current serving BS. 

7.5 Timebase counters for QAIVI 

7.5.1 Timing counters for QAIVI 

The timing state of the signals transmitted by a BS or MS on a QAM channel shall be defined by the following 
counters: 

• QAM Symbol Number (SN-Q)(1 - 34); 

• Timeslot Number (TN)(1 - 4); 

• TDMA Frame Number (FN)(1 - 18); 

• TDMA Multiframe Number iMN)(l - 60). 

The timing of QAM channels of a BS shall be synchronized to the timing of the phase modulated channels of the BS. 
This shall be done so that: 

• The start of timeslots on QAM channels shall be synchronized with the start of timeslots on phase modulated 
channels of the BS (within the accuracy specified in clause 7.7). This means that for continuous downlink 
transmission, the symbol time of SN-Ql on QAM channels shall be coincident with the symbol time of SNO 
(SN255 of the previous timeslot) on phase modulated channels of that BS (within the accuracy specified in 
clause 7.7); 

• 77V, FN and MA' shall be synchronized for QAM channels and phase modulated channels of the BS. 

7.5.2 Values of the counters for QAM 

The relationship between these counters shall be as follows: 

• SN-Q increments every 5/12 msec (for an MS, this holds unless otherwise required by the mobile timebase 
adjustment); 

• TN increments at the beginning of each timeslot (at symbol time of SN-Ql on the downlink); 

• FN increments whenever TN changes from count 4 to 1 ; 
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• MA^ increments whenever FA^ changes from 18 to 1. 

The simultaneous change of state of all counters to 1 defines the timebase reference. 

7.6 Timing of transmitted signals for QAIVI 

The timing of modulation symbols transmitted by the MS and BS on a QAM channel is defined in clause 9. 

The initial values of the TN, FN and MN counters are transmitted by the BS only in a synchronization burst on phase 
modulated channels as defined in clause 9. Therefore these counters can be initialized by MS only when the MS is on a 
phase modulated channel. 

On a QAM channel, the MS shall set-up its timebase counters as follows: 

• SN-Q shall be set by the timing of the synchronization symbols; 

• The value of TN, FN and MN shall be retained from the values read from the BSCH on one of the phase 
modulated channels of the BS. While being on a QAM channel, the MS shall update 77V, FN and MN as defined 
in clause 7.4 and clause 7.5.2. 

7.7 BS requirements for synchronization 

The BS shall use a single frequency source with accuracy better than +0,2 ppm (+0,1 ppm for frequencies above 

520 MHz) for both RF frequency generation and clocking the timebase. The same source shall be used for all carriers of 

the BS. 

It is optional whether the timebase counters of different BSs are synchronized together. 

The channels of different carriers transmitted by a BS shall be synchronized together, i.e. controlled by the same set of 
counters. The timing difference between the start of timeslot on different carriers shall be less than 125/9 |is. In case of 
timesharing of the same carrier by different BSs, the timing difference between the timebase references of two any such 
BS shall be less than 250/9 |is. 

7.8 IVIS requirements for synchronization 

The MS shall only transmit to the BS if the requirements of items a) to c) below are met. 

a) The MS carrier frequency shall be accurate to within +100 Hz compared to signals received from the BS (these 
signals may have an apparent frequency error due to BS frequency error and Doppler shift). The signals from the 
BS shall be averaged by the MS over sufficient time that errors due to noise or interference are allowed for 
within the above +100 Hz figure. 

b) The MS shall adjust its internal timebase in line with that of signals received from the BS. If the MS determines 
that the timing difference exceeds 125/9 |is, it shall adjust its timebase in steps of not greater than 125/9 |is. This 
adjustment shall be performed at intervals of not less than 1 second and not greater than 3 seconds until the 
timing difference is less than 125/9 |is. 

c) In determining the timing of signals from the BS, the timings shall be assessed in such a way that the timing 
assessment error is less than 125/18 |is. The assessment algorithm shall be such that the requirements of (b) can 
be met. 

The conditions under which the requirements of items a) to c) shall be met shall be 3 dB below the reference sensitivity 
level defined in clause 6 and 3 dB less carrier to interference ratio than the reference interference ratios defined in 
clause 6. Static or dynamic reference sensitivity levels shall be used depending on the applied propagation conditions. 
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8 Channel coding and scrambling 



8.1 



Introduction 



A reference configuration of the TETRA transmission chain is given in clause 4. According to the reference 
configuration, clause 8 defines the error control process which applies to the information bits packed in MAC blocks 
(see definition in clause 19), and which provides multiplexed bits packed in multiplexed blocks. 

Clause 8 applies to all logical channels, however channel coding for speech service is defined in EN 300 395-2 [21] 
clause 5. The definition of logical channels is given in clause 9. 

Clause 8 includes the specification of encoding, re-ordering and interleaving, and scrambling, but does not specify any 
data processing on the receive part. 

A definition of the error control process is provided for each kind of logical channel. 

8.2 General 

8.2.1 Interfaces in the error control structure 



8.2.1 .1 Interfaces for phase modulation 

information bits in MAG blocks 

(1) type-1 bits in type-1 blocks 

\/ 



block- 
encoding 



block-encoded bits 



I (2) type-2 bits in type-2 blocks 
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\/ N/ 



tail bits 



convolutional 
encoding 



(3) type-3 bits in type-3 blocks 



convolutionally-encoded bits 
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e (4) type-4 bits in type-4 blocks 
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re-ordering/ 
interleaving 



interleaved bits 



\y 



scrambling 



scrambled bits 



\|/ 



(5) type-5 bits in type-5 blocks 

to the multiplexed blocks 
Figure 8.1 : Interfaces in tlie error control structure for phase modulation 
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The definition of interfaces within the error control structure is given by figure 8.1. 

Each logical channel shall have its own error control scheme. For each one, the information bits (eventually including a 
MAC header) are referred to as type-1 bits. The type-1 bits are packed in MAC blocks (see clause 19), which are 
referred to as type-1 blocks, this defines interface (1) in figure 8.1. 

The processing in the transmit part shall be as follows: 

• the type-1 bits shall be encoded by a block code, providing block-encoded bits. In some cases tail bits shall be 
appended to these block-encoded bits. The block-encoded bits and the tail bits (if added) are referred to as 
type-2 bits and shall be packed in a type-2 block, this defines interface (2); 

the type-2 bits shall be encoded by a convolutional code, which provides the convolutionally encoded bits. The 
convolutionally-encoded bits are referred to as type-3 bits and shall be packed in a type-3 block, this defines 
interface (3); 

the type-3 bits shall be reordered and interleaved, into interleaved bits: the interleaved bits are referred to as 
type-4 bits and shall be packed in encoded blocks (see clause 19). Encoded blocks are referred to as 
type-4 blocks, this defines interface (4); 

the type-4 bits shall be scrambled, into type-5 bits, which compose type-5 blocks: this defines the interface (5). 
These bits shall then be mapped into multiplexed blocks. A multiplexed block shall be one of 5 different kinds: 
control block, BBK, synchronization block, block- 1 block, or block-2 block. 

All these operations are made on a per type-1 block basis. The sizes of type-1 blocks and of type-5 blocks and 
multiplexed blocks depend on the logical channel with which they are associated. 



• 



• 
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8.2.1.2 



Interfaces for QAM 



information bits in IVIAC blocl<s 
(1) type-1 bits in type-1 blocl<s 



block- 
encoding 



block-encoded bits 
(2) type-2 bits in type-2 blocks 



V ^ 



tail bits 



0) 

> 

O 
0) 



PCCC 
encoding 



(3) type-3 bits in type-3 blocks 



turbo-encoded bits 



interleaving 



(4) type-4 bits in type-4 blocks 



interleaved bits 



scrambling 



(5) type-5 bits in type-5 blocks 



scrambled bits 



NOTE: The tail bits are used only if PCCC is used. 

Figure 8.2: Interfaces in thie error control structure for QAIVI 

The definition of interfaces within the error control structure is given by figure 8.2. Each logical channel shall have its 
own error control scheme. For each one, the information bits (possibly including a MAC header) are referred to as 
type-1 bits. The type-1 bits are packed in MAC blocks, which are referred to as type-1 blocks. This defines interface (1) 
in figure 8.2. 

The processing in the transmit part shall be as follows: 

• the type-1 bits shall be encoded by a block code, providing block-encoded bits. When the block-encoded bits 
are to be further encoded by a PCCC (see next point), three tail bits shall be appended to them. The 
block-encoded bits and the tail bits (if added) are referred to as type-2 bits and shall be packed in a 

type-2 block, this defining interface (2); 

• the type-2 bits shall be in some cases encoded by a parallel-concatenated convolutional code (hereinafter 
referred to as a PCCC), which provides the PCCC encoded bits. Alternatively, no further encoding shall be 
carried out on the type-2 bits (uncoded case). The PCCC encoded bits or alternatively the uncoded bits are 
referred to as type-3 bits and shall be packed in a type-3 block, this defining interface (3); 

• the type-3 bits shall be reordered into interleaved bits: the interleaved bits are referred to as type-4 bits and 
shall be packed in encoded blocks. Encoded blocks are referred to as type-4 blocks, this defining interface (4); 

• the type-4 bits shall be scrambled into type-5 bits, which compose type-5 blocks: this defines the interface (5). 

All these operations are made on a per type-1 block basis. The sizes of type-1 blocks and of type-5 blocks depend on the 
logical channel with which they are associated and on the modulation format and PCCC coding rate employed. 
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8.2.2 Notation 

For ease of understanding, a notation for bits and blocks is given for use throughout clause 8: 

• X is the interface number, as defined in figures 8.1 and 8.2; 

• « is a block number; 

• Bx(n) is the type-x block number n; 

• Kx is the number of bits that are carried by one type-x block; 

• A: is a bit number; 

• bx(n,k) is the bit number k in the type-x block number n; 

• alternatively bx(k) is the type-x bit number kina type-x block (for ease of notation), with k= I, 2,..., 
Kx and n = 1, 2,... 

The bits of the multiplexed blocks shall be denoted as: 

• cb(k): bit number k in an control block; 

• bb(k): bit number kina BBK; 

• sb(k): bit number kina synchronization block; 

• bknl(k): bit number A: in a block- 1 block; 

• bkn2(k): bit number A: in a block-2 block. 

8.2.3 Definition of error control codes 

8.2.3.1 1 6-state Rate-Compatible Punctured Convolutional (RCPC) codes 

The RCPC codes shall encode K2 type-2 bits b2(l), b2(2),..., b2(K2) into K3 type-3 bits /jjfij, b3(2),..., bs(Ks). This 
encoding shall be performed in two steps: 

• encoding by a 16-state mother code of rate 1/4; 

• puncturing of the mother code so to obtain a 16-state RCPC code of rate K2/KJ. 

A general description of these two steps is given in clauses 8.2.3.1.1 and 8.2.3.1.2 respectively. The puncturing 
co-efficients of the 16-state RCPC codes of rates 2/3, 1/3, 292/432 and 148/432 are given in clauses 8.2.3.1.3, 8.2.3.1.4, 
8.2.3.1.5 and 8.2.3.1.6 respectively. 

8.2.3.1 . 1 Encoding by the 1 6-state mother code of rate 1 /4 

The input to the mother code of any type-2 bit b2(k), k= 1,2,..., K2, implies the output, by the mother code, of 4 bits, 
denoted by V(M.k-l)+i), i = 1, 2, 3, 4, which shall be calculated as follows. 

Any of the 4 generator polynomials of the mother code, Gi(D), i= 1, 2, 3, 4, can be written as: 

G;[D)= ig^jDJ 

'=° for /= 1,2, 3,4 (8.1) 

Where gij = or 1,; = 0, 1, 2, 3, 4. 
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This means that the encoded bits are defined by: 

V{4{k-1) + i)= ib2{k-j)gij 

i=° for/= 1, 2, 3,4, andfe= 1, 2, ...,/:2 (8.2) 

Where the sum is meant modulo 2, and where b2(k -j) = for k <j. 

The generator polynomials of the mother code shall be: 

Gj(D) = 1 +D + D'f (8.3) 

G2(D) = 1 +D2 + D^ + D^ (8.4) 

G^(D) = 1 +D + D^ + 0^* (8.5) 

G^(D} = 1 +D + D^ + 0"^ (8.6) 

8.2.3.1 .2 Puncturing of the mother code 

The puncturing of the mother code into a 16-state RCPC code of rate {K2/K^) is achieved by selecting K^ type-3 bits out 
of the (4 K2) bits encoded by the mother code. This selection shall be as follows. 

Denoting by P(l), P{2), ..., P(t) the t puncturing coefficients (each one being equal to 1,2, 3, 4, 5, 6, 7 or 8), the 
type-3 bits are given by: 

b3(j) = V(k) fovj=l,2,-,K3 (8.7) 

with fc = 8 ((/ -1) div f) + P(i - t((i -1) div f)) 

Where / and f are defined in the following puncturing schemes. 

8.2.3.1 .3 Puncturing scheme of the RCPC code of rate 2/3 

The t = 3 puncturing co-efficients shall be: 

P(l) = 1, P(2) = 2, P(3) = 5, and / =; (8.8) 

8.2.3.1 .4 Puncturing scheme of the RCPC code of rate 1/3 

The t = 6 puncturing co-efficients shall be: 

P(l) = I, P(2) = 2, P(3) = 3, P(4) = 5, P(5) = 6, P(6) = 1, and / = ; (8.9) 

8.2.3.1 .5 Puncturing scheme of the RCPC code of rate 292/432 

The f = 3 puncturing co-efficients shall be: 

P(l) = 1, P(2) = 2, P(3) = 5, and / =j + (j - 1) div 65, with; = 1, 2, ..., 432 (8.10) 

8.2.3.1 .6 Puncturing scheme of the RCPC code of rate 148/432 

The f = 6 puncturing co-efficients shall be: 

P(l) = 1, P(2) = 2, P(3) = 3, P(4) = 5, P(5) = 6, P(6) = 7, and i = j +(j -1) div 35, with; = 1,2,..., 432 (8.11) 
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8.2.3.2 



Shortened (30,14) Reed-Muller (RM) code 



The shortened (30,14) RM code shall encode 14 type-1 bits bi(l), bi(2),..., bi(14) into 30 type-2 bits b2(l), b2(2),. 
b2(30). 



The vector of the 30 type-2 bits shall be derived from: 

[b2(l), b2(2),..., b2(30)] = [bi(l), bi(2),..., bi(14)] X G 
Where G is the generator matrix: 



(8.12) 



10 11 
10 1 

11111 



110 110 







10 1111 

10000100000 
1110000000111100 
1001100000111010 





1 
1 



1 





10 110 11 
110 10 111 







'14 



11111111110 11111 
1000001100111001 



010000101011010 
001000011010110 
000100100111001 
0000100101 10101 



0000010011100111 



(8.13) 



Where I74 denotes the (14 x 14) identity matrix. 



8.2.3.3 



{Ki + 1 6, Ki) block code 



The (K] + 16, Kj) code shall encode Kj type-1 bits b](l), bj(2), ..., b](K]) into (Kj + 16) type-2 bits b2(l), b2(2), 
b2(Kj + 16). The encoding rule shall be as follows (see ITU-T Recommendation X.25 [28]). 



The type-1 bits are treated as the co-efficients of the polynomial: 




M{X)= ib,{k)X^>-' 

k=1 


Let F(X) be: 


F{X) = 


(X^^M(X) + X'^' S X') modG(X) 


15 . 

+ IX' 

i=0 



Where all operations are meant modulo 2, and G(X) is the generator polynomial of the code: 

G(X) = X'6 + X'2 + X^ + 1 
F(X) is of degree 15, with co-efficients denoted by/(0), /(7 ),..., /(15): 



15 



F(X) = S f(i)X' 

i=0 



The K2 type-2 bits, with K2 = K + 16, are then given by: 

b2(k) = bi(k) for/t= 1,2,..., /T/.and 

b2(k) =f(Kj + 16-k) for k = Kj+\,Ki + 2,..., Kj + 16. 



(8.14) 



(8.15) 



(8.16) 



(8.17) 



(8.18) 
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8.2.3.4 



8-state Parallel Concatenated Convolutlonal Code (PCCC) for QAM 



With reference to figure 3, the PCCC shall encode K2 type-2 bits b2(l), b2(2),..., b2(K2) into Kj type-3 bits 
b3(l), b3(2),..., b3(K3). The K2 type-2 bits include two sets of 3 tail bits b2(K2 - 2), b2(K2 - 1), b2(K2) and 
b'2(K2 - 2), b'2(K2 - 1), b'2(K2), aimed at forcing the final state of the constituent recursive systematic convolutional 
(RSC) encoders to zero. The initial state of both constituent encoders shall be zero. As sketched in figure 8.3, this 
encoding shall be performed in four steps: 

a) encoding by a 8-state RSC encoder of rate 1/2 (the upper RSC encoder in figure 8.3); 

b) interleaving the input K2- 3 type-2 bits by means of a quadratic-congruence inner interleaver; 

c) encoding the interleaved bits by a second 8-state RSC encoder of rate 1/2 identical to the encoder in a), and 
retaining only the parity bits; 

d) puncturing the parity bits at the output of the two RSC encoders so to obtain an 8-state PCCC of overall rate 
K2/K3. 
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Figure 8.3: PCCC encoder 

A general description of these four steps is given in clauses 8.2.3.4.1, 8.2.3.4.2, 8.2.3.4.3 and 8.2.3.4.5, respectively. 
The puncturing scheme of the 8-state PCCC encoders of rates 2/3 and 1/2 are given in clauses 8.2.3.4.6 and 8.2.3.4.7, 
respectively. 

8.2.3.4.1 Encoding by the upper 8-state RSC encoder of rate 1/2 

The RSC upper encoder structure is shown in figure 8.4. The input to the RSC encoder of any type-2 bit b2(k), 
k = I, 2,..., K2, implies the output of 2 bits, denoted by Vi[2(k - 1) + i], i = 1, 2, which shall be calculated as follows. 



b,{k) 



b,(k) 




The first bit is systematic, i.e., 
Vi[2(k-l} + i] = b2(k) 



Figure 8.4: RSC encoder 



for fe = 1, 2,..., K2 and i=\. 



(8.19) 
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The second (parity) bit is generated through the generator G](D)/Go(D) where Go(D) and G](D) are polynomials 
identifying the recursive and non-recursive sections of the encoder, and can be written as: 



(=0 

3 

i=Q 

where go^o = 1 ^nd goj, i = 1, 2, 3, and gjj, i = 0, 1, 2, 3, are equal to or 1. 
This means that the parity bits are calculated as: 

3 3^ 

V,[2(k-l) + 2] = Y,V^[2(k-i-l) + 2]g^^+Y,Mk-i)g,^ for k= 1,2,..., K2, 



(8.20) 
(8.21) 



(8.22) 



where the sum is meant modulo 2, and where V][2(k - i - 1) + 2] = and b2(k - i) = for k < i. 
The generator polynomials of the parity bit shall be: 

GO(D) = 1 +D2 + D3 

G1(D) = 1 +D+D3 



(8.23) 
(8.24) 



The three type-2 tail bits b2(K2 - 2), b2(K2 - 1), b2(K2) depend on the state of the convolutional encoder after 
application of the bit b2(K2 - 3) to its input, and force the final encoder state to zero. The tail bits are chosen as shown 
in table 8.1. 

Table 8.1 : Tail bits for the RSC encoder 



Encoder state 


Tail bits 

b^K2-2)b^K2-1)b2(K2) 

b-2(K2-2)b'2(K2-1)b-2(K2) 


000 


000 


001 


100 


010 


110 


oil 


010 


100 


oil 


101 


111 


110 


101 


111 


001 



8.2.3.4.2 



Interleaving by the quadratic-congruence interleaver 



A quadratic-congruence block interleaver shall re-order K2- 3 type-2 bits b2(l), b2(2),..., b2(K2 - 3) into K2 - 3 
type-2 permuted bits b'2(l), b'2(2),..., b'2(K2 - 3), by means of the following two-step algorithm: 

a) first, the sequence of indices c^, m = 0, I,..., S - 1 is calculated, where S is the smallest power of 2 larger or 
equal than K2 - 3, as follows: 



: 0, and 



Cjfi = [cjfi-j + m/mod S, m = 1,2,..., S - 1 



(8.25) 
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b) Second, the K2 - 3 type-2 bits b2(l), b2(2 ),..., b2(K2 - 3) undergo the following procedure: 
flag <— false 

while i<(S- 2) 1 2 

y <r- [c + 5/2] mod S 

if (x< K^ andy < K^) 

swap bits b^{x + \) and b^{y + l) 

else if (x < K^ and y > /T^) 
if (flag = true) 

swapbits ^^(x + l) and ^^(f + 1) (8.26) 

flag <— false 
else 

t <— X 
flag <— true 

else if (x > A:^ and y < K^) 

if (flag = true) 

swap positions b^(y + l) and ^^^(f + l) 

flag <r- false 
else 

f ^y 

flag <— true 
! 4- / + 1 

Upon completion of the above procedure, the input sequence of K2 type-2 bits b2(l), b2(2 ),..., b2(K2) inclusive of the 
3 tail bits of table 8.1 is turned into the sequence of K2 type-2 interleaved bits b'2(l), b'2(2),..., b'2(K2). 

NOTE: Any bits that are not swapped remain in their orginal positions. 

8.2.3.4.3 Encoding the interleaved bits by the lower 8-state RSC encoder of rate 1/2 

This convolutional encoder shall be identical to the one described in clause 8.2.3.4.1 and shall operate on the sequence 
of ^2 type-2 interleaved bits b'2(l}, b'2(2),..., b'2(K2) yielding at its output the sequence denoted by V2[2(k - 1} + i], 
i = 1,2, k= 1, 2,..., K2- Only the sequence of parity bits is taken into account, that is generated as follows: 

3 3 

y, [2(k - 1) + 2] = X V, [2(k - / - 1) + 2]g„ , + Y,K(k - /)g, , for k=l, 2,..., K2, (8.27) 

(=1 (=0 

where the sum is meant modulo 2, and where V2[2(k - i - 1) +2] = and b'2(k - i) = for k < i. 

8.2.3.4.4 Merging the systematic and parity bits for the PCCC encoder 

The systematic and parity bits at the output of the two RSC encoders are merged together so as to generate a single 
sequence of 37^2 bits, as follows: 

fy. [k mod 3 + 2{k div 3)], {k - 1) mod 3 = 0, 1 
V{k) = { , k = l,2,---,3K, (8.28) 

I y2[2(fediv3)], (fe-l)mod3 = 2 
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8.2.3.4.5 



Puncturing scheme for the PCCC encoder 



Puncturing the sequence V(k), k = 1,2,..., 3K2 permits to achieve a code of rate K2/K^. This is done by selecting K^ 
type-3 bits out of the 3K^ encoded bits V(k), k = 1, 2,..., 3K2- This selection shall be as follows: 

Denoting by P(l); P(2);. ..; P(t) the t puncturing coefficients (each one being equal to 1,2, 3, 4, 5, 6, 7, 8, 9, 10, 11 or 
12), the type-3 bits are given by: 



b^Q) = V(k), j=l,2,...,K3, with k = 12[(i - l)div t ]+ Pfi -t[(i - 7jdiv t]} 
Where / and t are defined in the puncturing schemes defined in clauses 8.2.3.4.6 and 8.2.3.4.7. 

8.2.3.4.6 Puncturing scheme for the PCCC encoder with coding rate 2/3 



(8.29) 



The t = 6 puncturing co-efficients shall be: 

P(l) = 1, P(2) = 2, P(3) = 4, P(4) = 7, P(5) = 9, P(6) =10, and / =] 



8.2.3.4.7 



Puncturing scheme for the PCCC encoder with coding rate 1/2 



(8.30) 



The f = 8 puncturing co-efficients shall be: 

P(l) = 1, P(2) = 2, P(3) = 4, P(4) = 6, P(5) = 7, P(6) = 8, P(7) = 10, P(8) = 12, and / =j (8.31) 

8.2.3.5 (1 6,5) Reed-Muller (RM) code for QAM 

The (16,5) RM code shall encode 5 type-1 bits bi(l), bi(2),..., bi(5) into 16 type-2 bits b2(l), b2(2),..., b2(16). 

The vector of the 16 type-2 bits shall be derived from: 

[b2(l), b2(2),..., b2(16)] = [bid), bj(2),..., bi(5)] X G (8.32) 

where G is the generator matrix: 

^ 1 1 1 1 1 1 1 o' 

1111111 

I, 1 1 10 111 1 

10 1110 10 10 1 

110 1110 110 

Is denoting the (5 x 5) identity matrix. 



(8.33) 



8.2.4 Definition of interleaving sclnemes 



8.2.4.1 



Block Interleaving for phase modulation 



A (K,a) block interleaver shall re-order K^ type-3 bits b^(l), bj(2),..., b^(K^) into K4 type-4 bits b4(l), b4(2),..., b4(K4), 
with K = K^ = K4, in the following way: 



b4(k) = bM 



i = 1, 2,..., K 
with k=\ + ((ax i) mod K) 



(8.34) 
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8.2.4.2 



Interleaving over A/ blocks 



Interleaving over //blocks use two steps to interleave a sequence of Mtype-3 blocks Bj(l), B^(2),.. Bj(M) of 432 bits 
each into a sequence of (M + N - 1) type -4 blocks 84(1), 84(2), ...B4(M + N - 1) of 432 bits each, where M is an integer 
and //has values 1, 4, or 8. This interleaving shall be as follows. 

Firstly, a diagonal interleaver interleaves the M blocks 8^(1), 8^(2),. .B^iM) into (M+N-1) blocks B's(l), B'3(2),.. 
B's(M + N-1). Denoting by b'^(m,k) the k-th bit of block B'jfmj, with k=l, 2,.., 432 and m = 1, 2,..., M + N-1, 



b '3(m,k) = b^im - j, j+ 1 +('/ x N)) for 1 < m - j < M; 
b'3(m,k) = 0, otherwise; 



(8.35) 



with 



j = (k- 1) div (432/AO and i = (k- 1) mod (432/AO. 
A block interleaver then interleaves each block B'j(m) into type -4 block 84(111), m=\, 2,..M + N - 1: 

b4(m,i) = b'j(m,k} 
with 

k=\, 2,..., 432, and / = 1+ [(103 x k) mod 432] 



(8.36) 



8.2.4.3 



Block interleaving for QAM 



A (K, a) block interleaver shall re -order K^ type-3 bits b^(l), b^(2),..., b^(K^) into K4 type -4 bits b4(l), b4(2),..., b4(K4), 
with K = Kj = K4, in the following way: 



b4(k) = b3(i), i = 1,2,..., K 
with k = 1 + (a X /jmod K 



(8.37) 



The values of /T and a for the various logical channels, bandwidths and modulation formats are specified below in 
table 8.2(relevant to logical channels mapping on burst headers) and tables 8.3 to 8.6 (relevant to logical channels 
mapping on burst payloads). Detailed error control schemes for logical channels for QAM can be found in clause 8.3.2. 
The last row of table 8.2 means that the block-encoded bits relevant to logical channels SICH-Q/D and AACH-Q are 
merged together and then interleaved. 

Table 8.2: Values of /Cand a for logical channels mapping on burst headers, for any bandwidth 



Logical channel 


4/16/64-QAM 


SICH-Q/U 


K-=16, a=5 


SICH-Q/D + AACH-Q 


K=64, a=9 



Table 8.3: Values of /Cand a for logical channels mapping on burst payloads, 8 subcarriers 



Logical channel 


4-QAM 


16-QAM 


64-QAM 


SCH-Q/HU 


K-=152, a=13 


K=304, a=17 


K=456, a=23 


SCH-Q/U 


K=400, a=21 


K=800, a=29 


K-=1200, a=37 


SCH-Q/D, BNCH-Q 


K=408, a=23 


K=816, a=29 


K-=1224, a=35 


SCH-Q/RA 


K-=168, a=13 


- 


- 



Table 8.4: Values of /Cand a for logical channels mapping on burst payloads, 16 subcarriers 



Logical channel 


4-QAM 


16-QAM 


64-QAM 


SCH-Q/HU 


K-=320, a=17 


K=640, a=27 


K=960, a=31 


SCH-Q/U 


K-=816, a=29 


K-=1632, a=41 


K-=2448, a=49 


SCH-Q/D, BNCH-Q 


K-=880, a=29 


K-=176a a=41 


K-=2640, a=53 
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Table 8.5: Values of /Cand a for logical channels mapping on burst payloads, 32 subcarriers 



Logical channel 


4-QAM 


16-QAM 


64-QAM 


SCH-Q/HU 


K-=656, a=25 


K-=1312, a=37 


K-=1968, a=47 


SCH-Q/U 


K=^648,a=4^ 


K-=3296, a=57 


K-=4944, a=71 


SCH-Q/D, BNCH-Q 


K=1824, a=43 


K-=3648, a=61 


K-=5472, a=73 



Table 8.6: Values of /Cand a for logical channels mapping on burst payloads, 48 subcarriers 



Logical channel 


4-QAM 


16-QAM 


64-QAM 


SCH-Q/HU 


K-=992, a=33 


K=1984, a=45 


K-=2976, a=55 


SCH-Q/U 


K-=2480, a=49 


K=4960, a=71 


K-=7440, a=89 


SCH-Q/D, BNCH-Q 


K=2768, a=53 


K=5536, a=75 


K-=8304, a=91 



8.2.5 Definition of scrambling 



8.2.5.1 



Scrambling method 



Scrambling shall transform K4 type -4 bits b4(l), b4(2),..b4(K4) into K^ type-5 bits bs(l), b^(2),..b^(K^), with K^ = K4, as 
follows; 

b5(k) = b4(k) + p(k) for k= 1,2,..., K5 (8.38) 

Where the addition is meant modulo 2, and p(k) is the A:-th bit of the scrambling sequence. 

8.2.5.2 Scrambling sequence 

The scrambling sequence {p(k), k = 1, 2,..., K^} shall be generated from the 30 bits of the extended colour code e(l), 
e{2),.., e(30) (see clauses 19 and 23), except for the BSCH, by means of linear feedback registers. For the scrambling of 
BSCH, all bits e(l), e(2),.., e(30) shall be set equal to zero. 

The scrambling sequence generator shall be based upon the following connection polynomial: 



32 

c(x)= Sc,X' 

i=0 



(8.39) 



With c/ = 1 for i = 0, 1, 2, 4, 5, 7, 8, 10, 11, 12, 16, 22, 23, 26 and 32, and c,- = elsewhere and where all operations are 
meant modulo 2. The resultant polynomial is therefore: 



c(x) = 1 + X + X^ + X'^ + X^ + x^ + x^ + x^° + x^^ + x^^ + x^^ + X^^ + x^^ + x^^ + x^^ 



The k-th bit of the scrambling sequence is given by: 



32 



With the following initialization: 

p(k) = e(l-k) 
P(k) = 1 



p[k)= Tc,p{k-i) 



for;t=-29, -28,... 0;and 
for /t = -31, -30 



(8.40) 



(8.41) 



(8.42) 
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8.3 Error control schemes 

8.3.1 Error control schemes for phase modulation 

The error control scheme associated with each logical channel is defined in clauses 8.3.1.1 to 8.3.1.4 for phase 
modulation. Figures 8.5, 8.6 and 8.7 give the error control structure. 
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Figure 8.5: Error control structure for nJA DQPSK logical channels (part 1) 
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Figure 8.6: Error control structure for nJA DQPSK logical channels (part 2) 
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Figure 8.7: Error control structure for n/s D8PSK logical channels 



8.3.1 .1 Access Assignment Channel (AACH) 

One type-1 block shall contain 14 type-1 bits bj(l), bj(2),..., bj(14). 

A shortened (30,14) RM code (see clause 8.2.3.2) shall encode the 14 type-1 bits into 30 type -2 bits, b2(l), b2(2},..., 
b2(30}. 



The type -4 bits shall be the same as the type-2 bits; 

b4(k) = b2(k) forfe= 1,2,..., 30 



(8.43) 



The 30 type-4 bits b4(l), b4(2),..., b4(30), compose the type -4 block for AACH. They shall be scrambled into bits b^(l), 
bs(2),..., bs(30), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. The multiplexed 
bits of the BBK shall be defined as: 



bb(k) = bs(k), 



foik= 1,2,..., 30 



(8.44) 



8.3.1 .2 Broadcast Synchronization Channel (BSCH) 

One type-1 block shall contain 60 type-1 bits b](l), bj(2),..., b](60). 

A (76,60) block code shall encode the 60 type-1 bits into 76 block-encoded bits, b2(l), b2(2),...b2(76). This code is the 
(Kj + 16, Kj) block code as defined in clause 8.2.3.3, with Kj = 60. 

Four tail bits, b2(77), b2(78), b2(79), b2(80), all set equal to zero, shall be appended to the 76 block-encoded bits. 

The resultant bits b2(l), b2(2},..., b2(80) shall be the type-2 bits. 
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A 16-state RCPC code with rate 2/3 (see clause 8.2.3.1), shall encode the 80 type-2 bits into 120 type-3 bits, 
hd), bs(2),..., bsdlO). 

A (120, 1 1) block interleaving (see clause 8.2.4.1) shall re -order the 120 type-3 bits into 120 type -4 bits, b4(l) 
b4(2},..., b4(120). 

The 120 type -4 bits, b4(l), b4(2),..., b4(120) compose the type-4 block for BSCH. They shall be scrambled into bits 
bs(l), b^(2), ..., b^(120), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of the synchronization block shall be defined as: 

sb(k) = bsik), for k=\, 2,..., 120 (8.45) 

8.3.1 .3 Traffic channels in circuit switched mode 

8.3.1 .3.1 Frame stealing and multi-slot transmission 

In case frame stealing is activated for one of the data traffic channels defined in clauses 8.3.1.3.2 to 8.3.1.3.7 the 
multiplexed bits either of block- 1 or of block- 1 and block-2 are replaced by STCH bits. This means that the bits are 
replaced after coding, interleaving and scrambling. The construction of STCH bits is defined in clause 8.3.1.4.1. 

NOTE: Frame stealing on speech traffic channels modifies the type of logical channel which the speech channel 
encoder is using, refer to EN 300 395-2 [21] clause 5 and see notes in clauses 8.3.1.3.6 and 8.3.1.3.7. 

In the case of multi-slot transmission, up to four low bit rate traffic channels shall be multiplexed. This is further 
described in clause 23. 

8.3.1 .3.2 Traffic Channel, net rate = 4,8 kbit/s (TCH/4,8) 

A sequence of M type-1 blocks, Bj(m), m=\, 2,...M, shall be transmitted, whereby M is not limited. 

One type-1 block shall contain 288 type-1 bits, bi(l), bi(2),..., bi(288). 

The K2 = 292 type-2 bits shall comprise the 288 type-1 bits mapped as follows: 

b2(j) = bM for; =1,2,..., 288 (8.46) 

with the addition of four tail bits, b2(289), b2(290), b2(291), b2(292), all set equal to zero. 

A 16-state RCPC code with rate 292/432 (see clause 8.2.3.1) shall encode the 292 type-2 bits into 432 type-3 bits, 
bsd), bs(2),..., b3(432). 

An interleaving over A' blocks (see clause 8.2.4.2) shall interleave bits from M type-3 blocks (of 432 bits each) into 
(M+N-1) type-4 blocks (of 432 bits each): the bits in one type-4 block shall be denoted by b4(l), b4(2),..., b4(432). The 
parameter A^ shall be pre-set at the call set-up, and may take the values 1, 4 or 8. 

The 432 type-4 bits b4(l), b4(2),..., b4(432) shall compose the type-4 block for TCH/4,8. They shall be scrambled into 
bits bs(l), bs(2),..., bs(432), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of block- 1 are defined as: 

bkn](k) = b5(k), for k=l, 2,..., 216 (8.47) 

In case of frame stealing of block-1 bknl(l), bknl(2),..., bknl(216) shall be discarded, and replaced with the STCH bits 
as defined in clause 8.3.1.4.1 for block-1. 

The multiplexed bits of block-2 are defined as: 

bkn2(k) = b5(k+216), for k=\, 2,..., 216 (8.48) 

In case of frame stealing of block-2, bkn2(l),bkn2(2 ),..., bkn2(216) shall be discarded, and replaced with the STCH bits 
as defined in clause 8.3.1.4.1 for block-2. 
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8.3.1 .3.3 Traffic CHannel, net rate = 2,4 kbit/s (TCH/2,4) 

A sequence of M type-1 blocks, Bj(m), m=\, 2,...M, shall be transmitted, whereby M is not limited. 

One type-1 block shall contain 144 type-1 bits, b](l), b](2),..., b](144). 

The K2 = 148 type -2 bits shall comprise the 144 type-1 bits mapped as follows: 

b2(j) = bj(j), for; =1,2,..., 144 (8.49) 

with the addition of four tail bits, b2(145), b2(146), b2(147), b2(148), all set equal to zero. 

A 16-state RCPC code with rate 148/432 (see clause 8.2.3.1) encodes the 148 type-2 bits into 432 type-3 bits, 
bsd), bs(2),..., b3(432). 

An interleaving over N blocks (see clause 8.2.4.2) shall interleave bits from M type-3 blocks (of 432 bits each) into 
(M + N - 1) type -4 blocks (of 432 bits each): the bits in one type-4 block shall be denoted by b4(l), b4(2},..., b4(432). 
The parameter A' shall be pre-set at the call set-up, and may take the values 1, 4 or 8. 

The 432 type-4 bits b4(l), b4(2),..., b4(432) shall compose the type-4 block for TCH/2,4. They shall be scrambled into 
bits b^(l), b^(2),..., b^(432), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of block- 1 are defined as: 

bknl(k) = b5(k), for k=l, 2,..., 216 (8.50) 

In case of frame stealing of block-1 bknl(l), bknl(2),..., bknl(216) shall be discarded, and replaced with the STCH bits 
as defined in clause 8.3.1.4.1 for block-1. 

The multiplexed bits of block-2 are defined as: 

bkn2(k) = bs(k+2]6), for k=l, 2,..., 216 (8.51) 

In case of frame stealing of block-2, bkn2(l),bkn2(2),..., bkn2(216) shall be discarded, and replaced with the STCH bits 
as defined in clause 8.3.1.4.1 for block-2. 

8.3.1 .3.4 Traffic CHannel, net rate = 7,2 kbit/s (TCH/7,2) 

A sequence of M type-1 blocks, Bj(m), m=\, 2,..., M, shall be transmitted, whereby M is not limited. 

One type-1 block shall contain 432 type-1 bits, bi(l), bj(2),..., bj(432). 

There shall be 432 type-4 bits, which are the same as the type-1 bits: 

b4(k) = b](k), for fe = 1, 2,..., 432 (8.52) 

The 432 type-4 bit b4(l), b4(2),..., b4(432) shall compose the type-4 block for TCH/7,2. They shall be scrambled into 
bits bs(l), bs(2),..., bs(432), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of block-1 shall be defined as: 

bkn](k) = b5(k), for k=l, 2,..., 216 (8.53) 

In case of frame stealing of block-1 bknl(l), bknl(2),..., bknl(216) shall be discarded, and replaced with the STCH bits 
as defined in clause 8.3.1.4.1 for block-1. 

The multiplexed bits of block-2 shall be defined as: 

bkn2(k) = b5(k+216), for k=\, 2,..., 216 (8.54) 

In case of frame stealing of block-2, bkn2(l),bkn2(2 ),..., bkn2(216) shall be discarded, and replaced with the STCH bits 
as defined in clause 8.3.1.4.1 for block-2. 
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8.3.1 .3.5 Traffic Channel-P8, net rate = 1 0,8 kbit/s (TCH-P8/1 0,8) 

A sequence of M type-1 blocks, Bj(m), m=\, 2,..., M, shall be transmitted, whereby M is not limited. 

One type-1 block shall contain 648 type-1 bits, bi(l}, b](2),..., b](648). 

There shall be 648 type-4 bits, which are the same as the type-1 bits: 

b4(k) = bi(k), for k=l, 2,..., 648 (8.55) 

The 648 type-4 bit b4(l), b^l),..., b4(648) shall compose the type-4 block for TCH-P8/10,8. They shall be scrambled 
into bits b^(l), b^(2),..., b^(648), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of block- 1 shall be defined as: 

bkn](k) = b5(k), for k=l, 2,..., 324 (8.56) 

The multiplexed bits of block-2 shall be defined as: 

bkn2(k) = b5(k+324), for k=\, 2,..., 324 (8.57) 

8.3.1 .3.6 Speech Traffic Channel, full slot (TCH/S) 

EN 300 395-2 [21] defines in clause 5.5.3 432 type-4 bits €4(1), €4(2),..., C4(432). For the purpose of scrambling those 
bits are mapped into b4(k) = C4(k)for k = 1,2, ...,432. The b4(l), b4(2),..., b4(432) bits shall be scrambled into bits bs(l), 
bs(2),..., bs(432), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of block- 1 shall be defined as: 

bkn](k) = b5(k), for k=l, 2,..., 216 (8.58) 

and the multiplexed bits of block-2 shall be defined as: 

bkn2(k) = bs(k + 216), for k=l, 2,..., 216 (8.59) 

NOTE: It is considered that the MS is not stealing from a full slot speech channel but the MAC first informs the 
speech channel encoder which discards the type-1 bits of speech frame A and then uses half slot speech 
channel encoding for the type-1 bits of speech frame B. 

8.3.1 .3.7 Speech Traffic Channel, half slot (TCH/S) 

EN 300 395-2 [21] defines in clauses 5.4.3.2, 5.6.2 and 5.6.2.1 216 type-3 bits €3(1), €3(2),...., €3(216). For the 
purpose of further processing those bits are mapped into b3(k) = C3(k)fork = 1, 2,..., 216. 

As specified in EN 300 395-2 [21] clause 5.6.3, a (216, 101) block interleaver (see clause 8.2.4.1) shall re-order the 
216 type-3 bits b3(l), b3(2),..., b3(216), into 216 type-4 bits, b4(l), b4 (2),...., b4 (216). 

The 216 type-4 bits b4(l), b4(2),..., b4(216) shall compose the type-4 block for the half slot speech channel. They shall 
be scrambled into bits bs(l), b^(2), ..., b^(216), according to clause 8.2.5.1, with the scrambling sequence as defined in 
clause 8.2.5.2. 

The multiplexed bits of block-2 shall be defined as: 

bkn2(k) = b5(k), for k=l, 2,..., 216 (8.60) 

NOTE: The MAC does not use block- 1 for half slot speech transmission. 
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8.3.1 .4 Signalling channels for signalling and packet mode data 

8.3.1 .4.1 Signalling Channel for mapping onto Half-bursts on the Downlink (SCH/HD), 
Broadcast Network Channel (BNCH), and STealing Channel (STCH) 

One type-1 block shall contain 124 type-1 bits, b](l), b](2),..., b](124). 

A (140,124) block code shall encode the 124 type-1 bits into 140 block-encoded bits b2(l), b2(2),...b2(140). This code 
shall be the (Kj+16, Kj) block code as defined in clause 8.2.3.3, with Kj = 124. 

Four tail bits, b2(141), b2(142), b2(143), b2(144), all set equal to zero, shall be appended to the 140 block-encoded bits. 

The resultant bits b2(l), b2(2},..., b2(144) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see clause 8.2.3.1) shall encode the 144 type-2 bits into 216 type-3 bits, 
bsd), b3(2),..., b3(216). 

A (216,101) block interleaver (see clause 8.2.4.1) shall re-order the 216 type-3 bits into 216 type -4 bits, 
b4(l), b4(2),..., b4(216). 

The 216 type -4 bits fo^fij, b4(2),..., b4(216) shall compose the type-4 block for SCH/HD, BNCH, and STCH. They shall 
be scrambled into bits bs(l), bs(2), ..., bs(216), according to clause 8.2.5.1, with the scrambling sequence as defined in 
clause 8.2.5.2. 

The type-5 bits may be multiplexed onto block- 1, in which case the multiplexed bits are defined as: 

bknl(k) = bsik), for k=\, 2,..., 216 (8.61) 

or they may be multiplexed into block-2, in which case the multiplexed bits shall be defined as: 

bkn2(k) = bs(k), for k=l, 2,..., 216 (8.62) 

8.3.1 .4.2 Signalling Channel for mapping onto Half-bursts on the Downlink (SCH-P8/HD) 

One type-1 block shall contain 196 type-1 bits, bj(l), bj(2),..., bj(196). 

A (212,196) block code shall encode the 196 type-1 bits into 212 block-encoded bits b2(l), b2(2),..., b2(212). This code 
shall be the (Kj+16, Kj) block code as defined in clause 8.2.3.3, with Kj = 196. 

Four tail bits, b2(213), b2(214), b2(215), b2(216), all set equal to zero, shall be appended to the 216 block-encoded bits. 

The resultant bits b2(l), b2(2),..., b2(216) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see clause 8.2.3.1) shall encode the 216 type-2 bits into 324 type-3 bits, 
bsd), b3(2),..., b3(324). 

A (324,19) block interleaver (see clause 8.2.4.1) shall re-order the 324 type-3 bits into 324 type-4 bits, 
b4(l), b4(2),..., b4(324). 

The 324 type-4 bits b4(l), b4(2),..., b4(324) shall compose the type-4 block for SCH-P8/HD. They shall be scrambled 
into bits bs(l), bs(2), ..., bs(324), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The type-5 bits may be multiplexed onto block- 1, in which case the multiplexed bits are defined as: 

bkn](k) = bs(k), for k=l, 2,..., 324 (8.63) 

or they may be multiplexed into block-2, in which case the multiplexed bits shall be defined as: 

bkn2(k) = b5(k), for k=l, 2,..., 324 (8.64) 
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8.3.1 .4.3 Signalling Channel for mapping onto Half-bursts on the Uplink (SCH/HU) 

One type-1 block shall contain 92 type-1 bits bj(l), bj(2),..., bj(92). 

A (108,92) block code shall encode the 92 type-1 bits into 108 block-encoded bits, b2(l), b2(2),...b2(108). This code is 
the (K]+16, Kj) block code as defined in clause 8.2.3.3, with K]= 92. 

Four tail bits, b2(109), b2(110), b2(lll), b2(112), all set equal to zero, shall be appended to the 108 block-encoded bits. 

The resultant bits b2(l), b2(2),..., b2(112) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see clause 8.2.3. 1) shall encode the 112 type-2 bits into 168 type-3 bits, 
bsd), b3(2),..., b3(168). 

A (168, 13) block interleaver (see clause 8.2.4.1) shall re-order the 168 type-3 bits into 168 type-4 bits, 
b4(l), b4(2),..., b4(168). 

The 168 type-4 bits b4(l), b4(2),..., b4(168) shall compose the type-4 block for SCH/HU. They shall be scrambled into 
bits b^(l), b^(2), ..., b^(168), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of the control block (which is the type-5 block for SCH/HU) are defined as: 

cb(k) = bs(k), for k=l, 2,..., 168 (8.65) 

8.3.1 .4.4 Signalling Channel for mapping onto Half-bursts on the Uplink (SCH-P8/HU) 

One type-1 block shall contain 148 type-1 bits b](l), b](2),..., b](148). 

A (164,148) block code shall encode the 148 type-1 bits into 164 block-encoded bits, b2(l), b2(2),...b2(164). This code 
is the (Kj+16, Kj) block code as defined in clause 8.2.3.3, with Kj = 148. 

Four tail bits, b2(165), b2(166), b2(167), b2(168), all set equal to zero, shall be appended to the 164 block-encoded bits. 

The resultant bits b2(l), b2(2),..., b2(168) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see clause 8.2.3.1) shall encode the 168 type-2 bits into 252 type-3 bits, 
bsd), b3(2),..., b3(252). 

A (252, 17) block interleaver (see clause 8.2.4.1) shall re-order the 252 type-3 bits into 252 type-4 bits, 
b4(l), b4(2),..., b4(252). 

The 252 type-4 bits fo^fi), b4(2),..., b4(252) shall compose the type-4 block for SCH-P8/HU. They shall be scrambled 
into bits bs(l), bs(2), ..., bs(252), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of the control block (which is the type-5 block for SCH-P8/HU) are defined as: 

cb(k) = bs(k), for k=l, 2,..., 252 (8.66) 

8.3.1 .4.5 Signalling Channel for mapping onto Full bursts (SCH/F) 

One type-1 block shall contain 268 type-1 bits, b](l), b](2),..., b](268). 

A (284,268) block code shall encode the 268 type-1 bits into 284 block-encoded bits b2(l), b2(2),...b2(284). This code 
shall be the (Ki+16, Kj) block code as defined in clause 8.2.3.3, with Kj = 268. 

Four tail bits, b2(285), b2(286), b2(287), b2(288), all set equal to zero, shall be appended to the 284 block-encoded bits. 

The resultant bits b2(l), b2(2},..., b2(288) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see clause 8.2.3.1) encodes the 288 type-2 bits into 432 type-3 bits, 
bsd), b3(2),..., b3(432). 
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A (432,103) block interleaver (see clause 8.2.4.1) shall re-order the 432 type-3 bits into 432 type-4 bits, 
b4(l), b4(2),..., b4(432). 

The 432 type-4 bits b4(l), b4(2),..., b4(432) shall compose the type-4 block for SCH/F. They shall be scrambled into bits 
bs(l), bs(2), ..., bs(432), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of block- 1 are defined as: 

bkn](k) = bs(k), for k=l, 2,..., 216 (8.67) 

and the multiplexed bits of block 2 are defined as: 

bkn2(k) = bs(k+2]6), for k=l, 2,..., 216 (8.68) 

8.3.1 .4.6 Signalling CHannel for mapping onto Full bursts (SCH-P8/F) 

One type-1 block shall contain 412 type-1 bits, b2(l), bj(2),..., bj(412). 

A (428,412) block code shall encode the 412 type-1 bits into 428 block-encoded bits b2(l), b2(2),...b2(428). This code 
shall be the (Kj+16, Kj) block code as defined in clause 8.2.3.3, with Kj = 412. 

Four tail bits, b2(429), b2(430), b2(431), b2(432), all set equal to zero, shall be appended to the 428 block-encoded bits. 

The resultant bits b2(l), b2(2),..., b2(432) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see clause 8.2.3.1) encodes the 432 type-2 bits into 648 type-3 bits, 
bsd), b3(2),..., b3(648). 

A (648,23) block interleaver (see clause 8.2.4.1) shall re-order the 648 type-3 bits into 648 type-4 bits, 
b4(l), b4(2),..., b4(648). 

The 648 type-4 bits b4(l), b4(2),..., b4(648) shall compose the type-4 block for SCH-P8/F. They shall be scrambled into 
bits bs(l), bs(2), ..., bs(648), according to clause 8.2.5.1, with the scrambling sequence as defined in clause 8.2.5.2. 

The multiplexed bits of block- 1 are defined as: 

bkn](k) = bs(k), for k=l, 2,..., 324 (8.69) 

and the multiplexed bits of block 2 are defined as: 

bkn2(k) = b5(k+324), for k=l, 2,..., 324 (8.70) 
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8.3.2 Error control schemes for QAM 

The error control scheme associated with each logical channel employing QAM is defined in clauses 8.3.2.1 to 8.3.2.7. 
Figure 8.8 gives the error control structure. 
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Figure 8.8: Error control structure for QAM logical channels 

8.3.2.1 Slot Information Channel - QAM/Uplink (SICH-Q/U) 

A type-1 block shall contain 5 type-1 bits bj(l), bj(2 ),..., bj(5). 

A (16,5) RM code (see clause 8.2.3.5) shall encode the 5 type-1 bits into 16 type -2 bits, b2(l), b2(2),..., b2(16). 

The type-3 bits shall be the same as the type -2 bits: 

b3(k) = b2(k), k=l, 2,..., 16 (8.71) 

The 16 type-3 bits fej('7), bs(2),..., bs(16) compose the type-3 block for SICH-Q/U. They shall be interleaved into 16 
type-4 bits b4(l), b4(2),..., b4(16) according to clause 8.2.4.3, with interleaving parameters given by the second row of 
table 8.2. 

The 16 type-4 bits b4(l), b4(2),..., b4(16) shall be scrambled into 16 type-5 bits bs(l), b^(2), ..., b^(16) according to 
clause 8.2.5.1, with scrambling sequence as defined in clause 8.2.5.2. 
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8.3.2.2 Slot Information Channel - QAM/Downlink (SICH-Q/D) 

A type-1 block shall contain 5 type-1 bits bj(l), bj(2 ),..., bj(5). 

A (16,5) RM code (see clause 8.2.3.5) shall encode the 5 type-1 bits into 16 type-2 bits, b2(l), b2(2),..., b2(16). 

The type-3 bits shall be the same as the type-2 bits: 

b3(k) = b2(k), /t= 1,2,..., 16 (8.72) 

The 16 type-3 bits b3(l), b3(2),..., bj(16) compose the type-3 block for SICH-Q/D. As described in clause 8.3.2.3, they 
shall be merged with the type-3 bits relevant to the AACH-Q and shall then undergo block interleaving and scrambling. 

8.3.2.3 Access Assignment Channel - QAM (AACH-Q) 

A type-1 block shall contain 15 type-1 bits bj(l), bj(2),..., bj(15). This sequence is split into three 5-bit sub-sequences, 
as follows: 

• Pt sub-sequence: bi(l), bi(2),..., bi(5); 

• 2nd sub-sequence: bi(6), bi(7),..., bi(lO); 

• 3"^ sub-sequence: bi(l 1), bi(12),. . ., bi(15). 

A (16,5) RM code (see clause 8.2.3.5) shall encode each of the above three sub-sequences into 16 type-2 bits, as 
follows: 

• the sequence bj(l), bj(2),..., bj(5) shall produce the sequence b2(l), b2(2),..., b2(16); 

• the sequence bj(6), bj(7),..., bj(lO) shall produce the sequence b2(17), b2(18),..., b2(32); 

• the sequence bj(ll), bj(12),..., bj(15) shall produce the sequence b2(33), b2(34),..., b2(48). 
The three encoded sequences are then merged into a single 48 type-2 bits sequence b2(l), b2(2 ),..., b2(48). 
The type-3 bits shall be the same as the type-2 bits: 

b3(k) = b2(k), /t = 1, 2,..., 48 (8.73) 

The 48 type-3 bits fe^fij, b3(2 ),..., b3(48) compose the type-3 block for AACH-Q. They shall be merged with the type-3 
bits relevant to the SICH-Q/D so as to generate the 64 type-3 bits b'^il), b'3(2),..., b'3(64), as follows: 

• the first 16 bits ^'jfij, b'3(2},..., b'^ilG) shall coincide with the type-3 block for SICH-Q/D (see 
clause 8.3.2.2); 

• the remaining 48 bits b's(17}, b'3(18),..., b'04} shall coincide with the type-3 block for AACH-Q. 

The 64 type-3 bits b's(l), b's(2),..., b's(64) shall be interleaved into 64 type-4 bits b4(l), b4(2 ),..., b4(64) according to 
clause 8.2.4.3, with interleaving parameters given by the last row of table 8.2. 

The 64 type-4 bits b4(l), b4(2 ),..., b4(64) shall be scrambled into 64 type -5 bits ^jfi), bs(2 ),..., bs(64) according to 
clause 8.2.5.1, with scrambling sequence as defined in clause 8.2.5.2. 

8.3.2.4 Signalling Channel - QAM/Half slot Uplink (SCH-Q/HU) 

One type-1 block shall contain Kj type-1 bits bj(l), bj(2),..., bj(Kj) where Kj depends on the bandwidth, the 
modulation and the PCCC coding rate. Table 8.7 shows the values of Kj for all allowed bandwidths, modulations and 
coding rates. 
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Table 8.7: Values of Ki for logical channel SCH-Q/HU 



Number of 
sub-carriers 


4-QAM 


16-QAM 


64-QAM 


r = 1/2 


r = 1/2 


uncoded 


r = 1/2 


r = 2/3 


uncoded 


8 


57 


133 


288 


209 


285 


440 


16 


141 


301 


624 


461 


621 


944 


32 


309 


637 


1296 


965 


1293 


1952 


48 


477 


973 


1968 


1469 


1965 


2960 



A (Kj +16, Kj) block code shall encode the Kj type-1 bits into A'; + 16 block-encoded type-2 bits 

b2(l), b2(2),..., b2(Kj + 16j. This code is the (Kj + 16, Kj) block code defined in clause 8.2.3.3, with Kj one of the 

values of table 8.7. 

In case a PCCC encoder is used with coding rate r equal to 1/2 or 2/3 (see clause 8.2.3.4), three tail bits, b2(K] + \1), 
b2(Kj + 18j, b2(Kj + 19j, whose values are as specified in table 8.1, shall be appended to the Kj + 16 block-encoded 
bits. If PCCC is not used (uncoded case), no tail bits shall be appended to the Kj + 16 block-encoded bits. 

The resultant bits b2(l), b2(2),..., b2(K2) shall be the type-2 bits , with K2 = Kj + 19 or K2 = Kj + 16 depending on 
whether PCCC is used or not, respectively. 

As already mentioned, a PCCC scheme with coding rate r equal to 1/2 or 2/3 may be used to encode the K2 type-2 bits 
into K^ type-3 bits, b^(l), b^(2),..., b^(K^). Alternatively, no PCCC encoder may be used (uncoded case) and in this case 
K^ = K2 = Kj + 16. The possible values of K^ depending on bandwidth and modulation are shown in table 8.8. 

Table 8.8: Values of /C^for logical channel SCH-Q/HU 



Number of 
subcarriers 


4-QAM K3 


16-QAM 
K3 


64-QAM 
K3 


8 


152 


304 


456 


16 


320 


640 


960 


32 


656 


1312 


1968 


48 


992 


1984 


2976 



A (K^, a) block interleaver (see clause 8.2.4.3, tables 8.3 to 8.6) shall re-order the Kj type3 bits into K4 = Kj type-4 bits, 
b4(l), b4(2),..., b4(K4). The K4 type-4 bits b4(l), b4(2),..., b4(K4) shall compose the type-4 block for SCH-Q/HU. They 
shall be scrambled into K^ = K4 bits b^(l), b^(2),..., b^iK^), according to clause 8.2.5.1, with the scrambling sequence as 
defined in clause 8.2.5.2. 



8.3.2.5 



Signalling Channel - QAM/Uplink (SCH-Q/U) 



One type-1 block shall contain Kj type-1 bits bi(l), b](2),..., bj(Kj), where Kj depends on the bandwidth, the 
modulation and the PCCC coding rate. Table 8.9 shows the values of Kj for all allowed bandwidths, modulations and 
coding rates. 

Table 8.9: Values of Ki for logical channel SCH-Q/U 



Number of 
sub-carriers 


4-QAM 


16-QAM 


64-QAM 


r = 1/2 


r = 1/2 


uncoded 


r = 1/2 


r = 2/3 


uncoded 


8 


181 


381 


784 


581 


781 


1184 


16 


389 


797 


1616 


1205 


1613 


2432 


32 


805 


1629 


3280 


2453 


3277 


4928 


48 


1221 


2461 


4944 


3701 


4941 


7424 



A (Kj +16, Kj) block code shall encode the Kj type-1 bits into Kj + 16 block-encoded type-2 bits 

b2(l), b2(2),..., b2(Kj + 16). This code is the (Kj + 16, Kj) block code defined in clause 8.2.3.3, with Kj one of the 

values of table 8.9. 
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In case a PCCC encoder is used with coding rate r equal to 1/2 or 2/3 (see clause 8.2.3.4), three tail bits, b2(Ki + 11), 
b2(Kj + 18j, b2(Kj + 19j, whose values are as specified in table 8.1, shall be appended to the Kj + 16 block-encoded 
bits. If PCCC is not used (uncoded case), no tail bits shall be appended to the Kj + 16 block-encoded bits. 



The resultant bits b2(l), b2(2),..., b2(K2) shall be the type-2 bits, with K2 ■ 
whether PCCC is used or not, respectively. 



Kj + 19 ov K2 = Kj + 16 depending on 



As already mentioned, a PCCC scheme with coding rate r equal to 1/2 or 2/3 may be used to encode the K2 type-2 bits 
into Kj type-3 bits, bj(l), bj(2),..., bj(Kj). Alternatively, no PCCC encoder may be used (uncoded case) and in this case 
K^ = K2 = Kj + 16. The possible values of K^ depending on bandwidth and modulation are shown in table 8.10. 

Table 8.10: Values of /Csfor logical channel SCH-Q/U 



Number of 
subcarriers 


4-QAM K3 


16-QAM 
K3 


64-QAM 
K3 


8 


400 


800 


1200 


16 


816 


1632 


2448 


32 


1648 


3296 


4944 


48 


2480 


4960 


7440 



A (K^, a) block interleaver (see clause 8.2.4.3, tables 8.3 to 8.6) shall re-order the K^ type-3 bits into K4 = K^ type -4 
bits, b4(l), b4(2),..., b4(K4). The K4 type-4 bits b4(l), b4(2),..., b4(K4) shall compose the type-4 block for SCH-Q/U. 
They shall be scrambled into K^ = K4 bits b^(l), b^(2),..., b^(K^), according to clause 8.2.5.1, with the scrambling 
sequence as defined in clause 8.2.5.2. 

8.3.2.6 Signalling Channel - QAIVI/Downlink (SCH-Q/D) and Broadcast Network 

Channel - QAM (BNCH-Q) 

One type-1 block shall contain Kj type-1 bits bj(l), bj(2),..., bj(Kj), where Kj depends on the bandwidth, the 
modulation and the PCCC coding rate. Table 8.11 shows the values of Kj for all allowed bandwidths, modulations and 
coding rates. 

Table 8.11 : Values of Ki for logical channels SCH-Q/D and BNCH-Q 



Number of 
sub-carriers 


4-QAM 


16-QAM 


64-QAM 


r = 1/2 


r = 1/2 


uncoded 


r = 1/2 


r = 2/3 


uncoded 


8 


185 


389 


800 


593 


797 


1208 


16 


421 


861 


1744 


1301 


1741 


2624 


32 


893 


1805 


3632 


2717 


3629 


5456 


48 


1365 


2749 


5520 


4133 


5517 


8288 



A (Kj h- 16, Kj) block code shall encode the Kj type-1 bits into Kj + 16 block-encoded type-2 bits 

b2(l), b2(2),..., b2(Kj + 16). This code is the (Kj + 16, Kj) block code defined in clause 8.2.3.3, with Kj one of the 

values of table 8.11. 

In case a PCCC encoder is used with coding rate r equal to 1/2 or 2/3 (see clause 8.2.3.4), three tail bits, b2(Kj + 17), 
b2(Kj + 18), b2(Kj + 19), whose values are as specified in table 8.1, shall be appended to the Kj + 16 block-encoded 
bits. If PCCC is not used (uncoded case), no tail bits shall be appended to the Kj + 16 block-encoded bits. 



The resultant bits b2(l), b2(2),..., b2(K2) shall be the type-2 bits , with K2 ■ 
whether PCCC is used or not, respectively. 



Kj + 19 01 K2 = Kj + 16 depending on 



As already mentioned, a PCCC scheme with coding rate r equal to 1/2 or 2/3 may be used to encode the K2 type-2 bits 
into Kj type-3 bits, bj(l), bj(2),..., bj(Kj). Alternatively, no PCCC encoder may be used (uncoded case) and in this case 
Kj = K2 = Kj + 16. The possible values of ^^5 depending on bandwidth and modulation are shown in table 8.12. 
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Table 8.12: Values of Kaior logical channels SCH-Q/D and BNCH-Q 



Number of 
subcarriers 


4-QAM K3 


16-QAM 
K3 


64-QAM 
K3 


8 


408 


816 


1224 


16 


880 


1760 


2640 


32 


1824 


3648 


5472 


48 


2768 


5536 


8304 



A (K^, a) block interleaver (see clause 8.2.4.3, tables 8.3 to 8.6) shall re-order the K^ type-3 bits into K4 = Aj type -4 
bits, b4(]), b4(2),..., b4(K4). The K4 type-4 bits b4(l), b4(2),..., b4(K4) shall compose the type-4 block for SCH-Q/D or 
BNCH-Q. They shall be scrambled into K^ = K4 bits bs(l), b^(2),..., b^(K^) according to clause 8.2.5.1, with the 
scrambling sequence as defined in clause 8.2.5.2. 

8.3.2.7 Signalling Channel - QAM/Random Access (SCH-Q/RA) 

One type-1 block shall contain Kj = 65 type-1 bits b](l), b](2),..., b](65). 

A (81,65) block code shall encode the 65 type 1 bits into 81 block-encoded bits b2(l), b2(2),..., b2(81). This code shall 
be the (Kj + 16, Kj) block code defined in clause 8.2.3.3, with K^ = 65 . 

Three tail bits, b2(82), b2(83), b2(84), whose values are as specified in table 8.1, shall be appended to the 81 block- 
encoded bits. The resultant bits b2(l), b2(2),..., b2(K2), with K2 = 84, shall be the type -2 bits. 

A PCCC scheme with coding rate r equal to 1/2 shall be used to encode the 84 type-2 bits into Kj = 168 type-3 bits, 
b3(l), b3(2),..., b3(]68). 

A (168,13) block interleaver (see clause 8.2.4.3, table 8.3) shall re-order the 168 type-3 bits into K^ = K2= 168 type-4 
bits, b4(l), b4(2),..., b4(168). The type-4 bits b4(l), b4(2),..., b4(168) shall compose the type-4 block for SCH-Q/RA. 
They shall be scrambled into K^ = K4= 168 bits bs(l), bs(2),..., bs(168), according to clause 8.2.5.1, with the 
scrambling sequence as defined in clause 8.2.5.2. 
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Channel multiplexing 



9.1 Introduction 

Clauses 9.1 to 9.8 define the physical channels of the V+D radio sub-system required to support the logical channels. It 
includes a description of the logical channels and the definitions of TDMA frames, timeslots and bursts. 

9.2 Logical channels 

A logical channel is defined as a logical communication pathway between two or more parties. The logical channels 
represent the interface between the protocol and the radio subsystem. 

The definition of the logical channels that are supported by the radio subsystem is given below. 

9.2.1 Logical channels hierarchy 

The logical channels may be separated into two categories: the traffic channels carrying speech or data information in 
circuit switched mode and the control channels carrying signalling messages and packet data. The logical channels 
supported by the MAC are described here, with their hierarchical relationship. 

9.2.2 Traffic channels for 7r/4-DQPSK 

The traffic channels shall carry user information. Different traffic channels are defined for speech or data applications 
and for different data message speeds: 

• Speech Traffic Channel (TCH/S); 

• Circuit mode traffic channels as follows: 

7,2 kbit/s net rate (TCH/7.2); 

4,8 kbit/s net rate (TCH/4.8); 

2,4 kbit/s net rate (TCH/2.4). 

Higher net rate up to 28,8 kbit/s, 19,2 kbit/s or 9,6 kbit/s may be used. They are obtained by allocating up to 4 TP 
channels to the same communication. 

NOTE: Three different depths of interleaving (with N = 1, 4, or 8) may be applied to the traffic channels TCH/4,8 
and TCH/2,4 as detailed in clause 8.2.4.2. 

9.2.2a Traffic channels for 7r/8-D8PSK 

A single uncoded traffic channel is defined for 7t/8-D8PSK which enables nominal error rate references to be 
determined. 

• Uncoded traffic channel as follows: 

10,8 kbit/s net rate (TCH-P8/10,8). 
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9.2.3 Control Channels (CCH) for phase modulation 

9.2.3.1 General 

The CCH shall carry signalling messages and packet data. Five categories of control channel are defined: 

• Broadcast Control CHannel (BCCH); 

• Linearization CHannel (LCH); 

• SignalUng CHannel (SCH); 

• Access Assignment CHannel (AACH); and 

• STeaHng CHannel (STCH). 

9.2.3.2 BCCH 

The BCCH shall be a uni -directional channel for common reception by all MSs. It shall broadcast general information 
to all MSs. 

Two categories of BCCHs are defined, network and synchronization: 

• Broadcast Network Channel (BNCH): 

down-link only, broadcasts network information to MSs. 

• Broadcast Synchronization Channel (BSCH): 

down-link only, broadcast information used for time and scrambling synchronization of the MSs. 

9.2.3.3 LCH 

The LCH shall be used by the BSs and MSs to linearize their transmitter. 
Two categories of LCHs are defined, common and BS: 

• Common Linearization Channel (CLCH): 

up-link, shared by all the MSs; 

• BS Linearization CHannel (BLCH): 

downlink, used by the BS. 

9.2.3.4 SCH for 7r/4-DQPSK 

The SCH shall be shared by all MSs, but may carry messages specific to one MS or one group of MSs. System 
operation requires the establishment of at least one SCH per BS. SCH may be divided into 3 categories, depending on 
the size of the message: 

• Full size Signalling Channel (SCH/F): 

bi-directional channel used for full size messages. 

• Half size Downhnk Signalhng Channel (SCH/HD): 

downlink only, used for half size messages. 

• Half size Uplink Signalling Channel (SCH/HU): 

uplink only, used for half size messages. 
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9.2.3.4a SCH for tt/S-DSPSK 

As in the case of 71/4-DQPSK, the SCH may be divided into 3 categories, depending on the size of the message: 

• Full size Signalhng Channel (SCH-P8/F): 

bi-directional channel used for full size messages. 

• Half size Downlink Signalhng Channel (SCH-P8/HD): 

downlink only, used for half size messages. 

• Half size Uplink Signalhng Channel (SCH-P8/HU): 

uplink only, used for half size messages. 

9.2.3.5 AACH 

The AACH shall be present on all transmitted downlink slots. It shall be used to indicate on each physical channel the 
assignment of the uplink and downlink slots. The AACH shall be internal to the MAC. 

9.2.3.6 STCH 

The STCH is a channel associated to a TCH that temporarily "steals" a part of the associated TCH capacity to transmit 
control messages. It may be used when fast signalling is required. In half duplex mode the STCH is unidirectional and 
has the same direction as the associated TCH. 

9.2.4 QAM Control Channels (CCH-Q) 

9.2.4.1 General 

The CCH-Q shall carry signalling messages and packet data. Five categories of control channel are defined: 

• QAM Broadcast Control CHannel (BCCH-Q); 

• QAM Linearization CHannel (LCH-Q); 

• QAM Signalling CHannel (SCH-Q); 

• QAM Access Assignment CHannel (AACH-Q); and 

• QAM Slot Information CHannel (SICH-Q). 

9.2.4.2 BCCH-Q 

The BCCH-Q shall be a uni-directional channel for common reception by all MSs. It shall broadcast general 
information to all MSs. 

Only one category of BCCH-Q is defined in this version of the present document: 

• QAM Broadcast Network Channel (BNCH-Q): 

downlink only, broadcasts network information to MSs. 
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9.2.4.3 LCH-Q 

The LCH-Q shall be used by the base and MSs to linearize their transmitter. 
Two categories of LCH-Qs are defined, common and BS: 

• QAM Common Linearization Channel (CLCH-Q): 

uplink, shared by all the MSs; 

• QAM BS Linearization CHannel (BLCH-Q): 

downlink, used by the BS. 

Each of these two categories may be further subdivided according to channel bandwidth (25 kHz, 50 kHz, 100 kHz and 
150 kHz). For all channel bandwidths, the sole use of the LCH-Q is to linearize the transmitter using part of or all of the 
channel bandwidth. 

9.2.4.4 SCH-Q 

The SCH-Q shall be shared by all MSs, but may carry messages specific to one MS or one group of MSs. SCH-Q may 
be divided into 4 categories, depending on the direction, size and use of the message: 

• QAM Full size Downhnk Signalling Channel (SCH-Q/D): 

downlink only, used for full size messages. 

• QAM Full size Uplink Signalling Channel (SCH-Q/U): 

uplink only, used for full size messages. 

• QAM Half size Uphnk Signalling Channel (SCH-Q/HU): 

uplink only, used for half size messages. 

• QAM Random Access Uplink Signalhng Channel (SCH-Q/RA): 

uplink only, used for random access messages. 

Each of the first 3 categories may be further subdivided according to channel bandwidth (25 kHz, 50 kHz, 100 kHz and 
150 kHz), and modulation / coding combination. The fourth category (SCH-Q/RA) is 25 kHz only and fixed 
modulation / coding. 

For the first 3 categories, the channel subdivision is indicated as channel bandwidth followed by modulation followed 
by coding: 

SCH-Q/{DIUIHU} {25I50I100I150}-{4I16I64} {HIMIU} 

Where {DIUIHU} denotes one of D, U or HU indicating that the channel is for the downlink (D), uplink (U) or half slot 
uplink (HU) respectively, {4116164} denotes one of 4, 16 or 64 indicating that the channel is using 4-QAM, 16-QAM or 
64-QAM modulation, and {HIMIU} denotes one of H, M or U indicating that the channel is using high protection 
(rate 1/2) (H), medium protection (rate 2/3) (M) or unprotected (rate 1/1) (U). The SCH-Q/D channel for 25 kHz using 
4-QAM modulation and high protection (rate 1/2) is according to the naming convention named as SCH-Q/D25-4H. 

The total list of valid SCH-Q for 25 kHz operations is then: 

• SCH-Q/D25-4H, SCH-Q/D25-16H, SCH-Q/D25-64H, SCH-Q/D25-64M, SCH-Q/D25-16U, 
SCH-Q/D25-64U; 

• SCH-Q/U25-4H, SCH-Q/U25-16H, SCH-Q/U25-64H, SCH-Q/U25-64M, SCH-Q/U25-16U, 
SCH-Q/U25-64U; 

• SCH-Q/HU25-4H, SCH-Q/HU25-16H, SCH-Q/HU25-64H, SCH-Q/HU25-64M, SCH-Q/HU25-16U, 
SCH-Q/HU25-64U; 

• SCH-Q/RA. 
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This gives a total of 19 SCH-Q for 25 kHz operations, and a total of 73 SCH-Q for all channel bandwidths. 

9.2.4.5 AACH-Q 

The AACH-Q shall be present on all transmitted downlink slots (except slots containing BLCH-Q). It shall be used to 
indicate on each QAM physical channel the assignment of the uplink and downlink slots. The AACH-Q shall be 
internal to the MAC. 

9.2.4.6 SICH-Q 

The SICH-Q shall be present on all transmitted slots, except slots carrying SCH-Q/RA or containing BLCH-Q. On the 
downlink, it shall be used to indicate the modulation and coding used in the remainder of the slot. On the uplink, it shall 
be used to indicate the modulation and coding used in the remainder of the slot or subslot. The SICH-Q shall be internal 
to the MAC. 

Two categories of SICH-Qs are defined, downlink and uplink: 

• QAM Downhnk Slot Information Channel (SICH-Q/D): 

downlink only, included in all downlink slots (except slots containing BLCH-Q); 

• QAM Uphnk Slot Information Channel (SICH-Q/U): 

uplink only, included in all uplink slots or subslots, except subslots carrying SCH-Q/RA or containing 
CLCH-Q. 

Each of the 2 categories may be further subdivided according to channel bandwidth (25 kHz, 50 kHz, 100 kHz and 
150 kHz). The notation for SICH-Q is: 

SICH-Q/{DIU} {2515011001150} 

NOTE 1: The content of the SICH-Q/D and SICH-Q/U channels is the same in all channel bandwidths. 

NOTE 2: The multiple channels are defined here for testing purpose. The target performance of the various 

channels will probably not vary significantly in terms of required Eb/NO as channel bandwidth changes, 
but as the fraction of power devoted to headers go down as channel bandwidth goes up, the "dBm" value 
will vary. 

9.3 The physical resource 
9.3.1 General 

The physical resource available to the radio sub-system is an allocation of part of the radio spectrum. This resource 
shall be partitioned both in frequency and time. Frequency shall be partitioned by RF channels divided into bands as 
defined in clause 6. Time shall be partitioned by timeslots and TDMA frames as defined in clauses 9.3.2 to 9.3.9. 

The access scheme shall be TDMA. 

The TDMA structure shall be composed of hyperframes, multiframes, frames, slots and subslots. Figure 9.1 repeats the 
representation of the TDMA structure given in figure 4.3. 
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Figure 9.1 : TDMA structure 

9.3.2 RF channels for phase modulation 

A RF channel is defined as a specified portion of the RF spectrum. Clause 6 defines the carrier separation which applies 
to TETRA channels. 

The DownLink (DL) comprises RF channels used in the BS to MS direction. 

The UpLink (UL) comprises RF channels used in the MS to BS direction. 

One pair of radio frequencies (uplink and downlink) of the cell allocation shall be used to carry the MCCH (see 
clauses 9.4.2.1 and 9.5.1) and shall be known as the main carrier. 

9.3.2a RF channels for QAM 

Clause 6 defines the carrier separation which applies to TETRA QAM channels. These channels can exist in addition to 
the phase modulation channels 

The DownLink (DL) comprises RF channels used in the BS to MS direction. 

The UpLink (UL) comprises RF channels used in the MS to BS direction. 

The QAM channel TDMA structure is identical to the phase modulation TDMA structure as shown in figure 9.L 

The phase modulation MCCH (see clauses 9.4.2.1 and 9.5.1) resides in the main carrier of cell allocation, and is 
common to the QAM channels. 
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9.3.2b Random access RF channels for QAM 

The Uplink Random Access comprises RF channels used in the MS to BS direction, see figure 9.2 
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Figure 9.2: Random access time / frequency structure 

9.3.3 Timeslots 

The basic unit of the TDMA structure is the timeslot. A timeslot shall have a duration of 85/6 ms (approximately 
14,17 ms) which corresponds to 255 phase modulation symbols duration in the Phase Modulation case and to 
34 symbols duration in the QAM case. 

9.3.4 TDMA frame 

Four timeslots shall form a TDMA frame. The TDMA frame has a duration of 170/3 ms (approximately 56,67 ms). 

The TDMA frames shall be numbered by a Frame Number (FN). The FN shall be cyclically numbered from 1 to 18. 
The FN shall be incremented at the end of each TDMA frame. 

The frame FN18 (also termed the control frame) shall be exclusively devoted to control channels. 

9.3.5 Timeslot numbering 

The timeslots within a TDMA frame shall be numbered from 1 to 4 and a particular timeslot shall be referenced by its 
Timeslot Number (TN). 

9.3.6 Subsiot 

The uplink timeslots may be divided into 2 subslots. The subslots within a timeslot shall be numbered from 1 to 2 and a 
particular subsiot shall be referenced by its SubSlot Number (SSN). 

A subsiot shall have a duration of 85/12 ms (approximately 7,08 ms) which corresponds to 127,5 phase modulation 
symbols duration in the Phase Modulation case and to 17 symbols duration in the QAM case. 

9.3.6a Random access uplink RF channel subslots for QAM 

For QAM, the random access uplink RF channel subslots shall be numbered from 1 1 and 21 in 25 kHz QAM channels, 
1 1 to 12 and 21 to 22 in 50 kHz QAM channels, 1 1 to 14 and 21 to 24 in 100 kHz QAM channels and 1 1 to 16 and 
21 to 26 in 150 kHz QAM channels. A particular random access uplink RF channel subsiot shall be referenced by its 
QAM Subsiot Number (SSN-Q). 
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A random access uplink RF channel subslot shall have a duration of 85/12 ms (approximately 7,08 ms), which 
corresponds to 17 symbols duration, and use 25 kHz of channel bandwidth, as depicted in figure 9.2. 

9.3.7 Multiframe 

Eighteen TDMA frames shall form a multiframe. The multiframe shall have a duration of 1,02 s. 

The multiframes shall be numbered by a Multiframe Number (MN). The MN shall be cyclically numbered from 1 to 60. 
The MN shall be incremented whenever the TDMA FN returns to 1 . 

9.3.8 Hyperframe 

The hyperframe shall be the longest recurrent time period of the TDMA structure. Sixty multiframes shall form 
a hyperframe. The hyperframe shall have a duration of 61,2 s. 

9.3.9 Frame alignment 

At the BS, the start of the hyperframe, multiframe and TDMA frame on the uplink shall be delayed by the fixed period 
of 2 timeslots from the start of the hyperframe, multiframe and TDMA frame on the downlink. 

9.4 Physical channels 

9.4.1 General 

A physical channel is defined by a pair of radio carrier frequencies (downlink and uplink) and a TN. There shall be 
4 physical channels per pair of radio frequencies. 

Clauses 9.4.2 to 9.4.5 apply to Phase Modulation channels. 

Clauses 9.4.6 to 9.4.9 apply to QAM channels. 

9.4.2 Types of physical channels for phase modulation 

Three types of physical channel are defined: 

• the Control Physical channel; 

• the Traffic Physical channel; and 

• the Unallocated Physical channel. 

The type of physical channel shall be indicated in the AACH. 

9.4.2.1 CP channel 

The CP channel is a physical channel carrying exclusively CCH. Two types of CP channels are defined: 

• the Main Control CHannel (MCCH); and 

• the Secondary Control CHannel (SCCH). 

In each cell one RF carrier shall be defined as the main carrier. Whenever a MCCH is used, the MCCH shall be located 
on the timeslot 1 of the main carrier. 

The SCCH may be used to extend the signalling capacity of the MCCH and may only be assigned when the MCCH is 
used. 

9.4.2.2 TP channel 

The TP channel is a physical channel carrying TCH. 
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9.4.2.3 UP channel 

The UP channel is a physical channel not allocated to one or more MS. 

9.4.3 Bursts for phase modulation 

9.4.3.1 General 

A burst is a period of RF carrier that is modulated by a data stream. A burst, therefore, represents the physical content of 
a timeslot or subslot. 

The description of a physical channel will be made in terms of timeslots and TDMA frames and not in terms of bursts. 
This is because there is not a one-to-one mapping between a particular physical channel and the use of a particular 
burst. 

A given physical channel shall use the same timeslot number in every TDMA frame. 

9.4.3.2 Phase modulation symbol numbering 

A timeslot shall be divided into 255 phase modulation symbol durations, each one with a duration of 1/18 ms 
(approximately 55,56 |is). A particular modulation symbol within a burst shall be referenced by a Symbol Number (SN), 
with the first modulation symbol numbered SNl and the last modulation symbol numbered SNmax. 

Different types of bursts are defined, having different durations. 

At the beginning of the transmission of a single burst or of consecutive bursts, a supplementary symbol SNO is defined. 
It does not carry information but shall be used as phase reference for the differential modulation. 

9.4.3.3 Phase modulation bit numbering 

In the following sections the content of the burst is defined in terms of phase modulation bits. 

A particular modulation bit within a burst shall be referenced by a Bit Number {BN), with the first modulation bit 
numbered BNl and the last modulation bit numbered BNmax. At the modulator the modulation bits shall be grouped 
together and converted into one modulation symbol as described in clause 5. 7t/4-DQPSK symbols contain two 
information bits and 7t/8-D8PSK symbols contain three information bits. 

9.4.3.4 Burst timing 

The symbol time is defined as the instant at which the transmitted symbol waveform is at a maximum for the symbol of 
interest. The timing of a modulation symbol is determined by its symbol time. 

The bits BN(2n-l) and BN(2n) shall determine the symbol SN(n) for 7t/4-DQPSK and the bits BN(3n-2), BN(3n-l) and 
BN(3n) shall determine the symbol SN(n) for jt/8-D8PSK. The symbol time of the modulation symbol SN(n) shall be 
delayed by (n+d) modulation symbol durations with respect to the start of the slot, with: 

• n: integer (1 to (SNmax)); 

• d: is defined as the burst delay. The burst delay represents the delay between the start of the timeslot and the 
symbol time of the symbol SNO. The burst delay shall be expressed in modulation symbol duration and varies 
with the type of burst and the SSN. The values of the burst delays are given in table 9.1. 

NOTE: Symbol time of the symbol SNO is same as symbol time of the symbol SN255 of the previous slot. 

The symbol time of the symbol SNO occurs one modulation symbol duration before the symbol time of the symbol SNl 
of the first burst of a transmission. 
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9.4.4 Type of bursts for phase modulation 
9.4.4.1 General 

Eight types of 71/4-DQPSK burst shall exist in the system. Figure 9.3 summarizes the description of the bursts and their 
timing with respect to the timeslot. Table 9.1 lists burst types. 

Five types of 7t/8-D8PSK burst shall exist in the system. Figure 9.3 summarizes the description of the 7t/8-D8PSK 
bursts and their timing with respect to the timeslot. 
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Figure 9.3: Types of bursts for phase modulation 
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NOTE 1: 71/8-D8PSK modulation is not used in the synchronization continuous down-link burst or the 

synchronization discontinuous down-link burst but may be used in all other types of burst. 7t/4-DQPSK 
modulation may be used for all types of burst. The modulation of the linearization up-link burst is 
undefined. 

NOTE 2: The power-time mask is defined in clause 6, figure 6.3 and table 6.8. The t^ period defined in clause 6, 
table 6.8 may be used for ramping and PA linearization. 

Table 9.1 : Burst types for Phase Modulation 



Burst type 


SNmax 


of burst delay (in symbol duration) 


Bit allocation 


SSN1 


SSN2 


control uplink (see note 1) 


103 


17 


144,5 


see clause 9.4.4.2.1 


linearization uplink 


not applicable 


not applicable 


not allowed 


see clause 6.4.5 


linearization downlink 


not applicable 


not allowed 


not applicable 


see clause 6.4.5 


normal uplink (see note 1) 


231 


17 


see clause 9.4.4.2.4 


normal continuous downlink 
(see note 1) 


255 





see clause 9.4.4.2.5 


synchronization 

continuous downlink (see note 2) 


255 





see clause 9.4.4.2.6 


normal discontinuous downlink 
(see note 1) 


246 


5 


see clause 9.4.4.2.7 


synchronization discontinuous 
downlink (see note 2) 


246 


5 


see clause 9.4.4.2.8 


NOTE 1 : IVIay use either 7i/4-DQPSK or 71/8-D8PSK modulation. 
NOTE 2: Shall use 7i/4-DQPSK modulation only. 



The generic name for normal continuous and discontinuous downlink burst is Normal Downlink Burst (NDB). The 
generic name for synchronization continuous and discontinuous downlink burst is Synchronization downlink Burst 
(SB). 



9.4.4.2 



Modulation bits allocation 



The bursts are divided into burst fields containing contiguous modulation bits of the same type. The burst fields are 
described in clause 9.4.4.3. 

The downlink bursts contain 3 independent blocks, called Broadcast Block (BBK), Block 1 (BKNl) and Block 2 
{BKN2). The normal uplink bursts contains two independent blocks, called Block 1 (BKNl) and Block 2 (BKN2). A 
separate logical channel may be mapped on each block. The broadcast block shall be made of the two scrambled 
broadcast bits fields and shall contain 30 bits. 

For 7t/4-DQPSK, block 1 and block 2 shall be made of one field and shall contain 216 scrambled bits. In the case of 
synchronization bursts, block 1 contains 120 bits. 

For J1/8-D8PSK, block 1 and block 2 shall be made of one field and shall contain 324 scrambled bits. 



9.4.4.2.1 



Control uplink Burst (CB) 



The allocation of the modulation bits in the 7t/4-DQPSK CB shall be in accordance with table 9.2 . The CB shall be 
used by MS to transmit control messages to the BS. 

Table 9.2: Control uplink Burst (CB) for 71/4-DQPSK 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 4 


4 


tail bits 


t1 to t4 


see clause 9.4.4.3.5 


5 to 88 


84 


scrambled control bits 


cb(1)tocfc>(84) 


see clause 8 


89 to 118 


30 


extended training sequence 


x1 to x30 


see clause 9.4.4.3.3 


119 to 202 


84 


scrambled control bits 


cb(85)tocfc>(168) 


see clause 8 


203 to 206 


4 


tail bits 


t1 to t4 


see clause 9.4.4.3.5 


NOTE: All fields shall be sent using 7i/4-DOPSK modulation. 
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The allocation of the modulation bits in the 7t/8-D8PSK CB shall be in accordance with table 9.3. The CB shall be used 
by MS to transmit control messages to the BS. 

Table 9.3: Control uplink Burst (CB) for jt/8-D8PSK 



Bit Number 
(BN) 


Field lengtli 
(bits) 


Field content 


Field bits number 


Definition 


1 to 6 


6 


tail bits -P8 


T1 to T6 


see clause 9.4.4.3.5 


7 to 132 


126 


scrambled control bits 


cb(1)tocfc>(126) 


see clause 8 


133 to 177 


45 


extended training sequence -P8 


X1 to X45 


see clause 9.4.4.3.3 


178 to 303 


126 


scrambled control bits 


cb(127)tocfc>(252) 


see clause 8 


304 to 309 


6 


tail bits -P8 


T1 to T6 


see clause 9.4.4.3.5 


NOTE: All fields shall be sent using 7t/8-D8PSK modulation. 



9.4.4.2.2 



Linearization uplink Burst (LB) 



The LB may be used by the MSs to linearize their transmitters. The LB contains no useful bits and its timing shall only 
be determined by the time mask (see clause 6). 



9.4.4.2.3 



Linearization downlink burst 



The linearization downlink burst replaces BKN2 of either a normal continuous downlink burst or a synchronization 
continuous downlink burst. 

The linearization downlink burst may be used by the BS to linearize its transmitter. The linearization downlink burst 
contains non useful bits and its timing shall be determined only by the time mask (see clause 6). 



9.4.4.2.4 



Normal Uplink Burst (NUB) 



The allocation of the modulation bits in the NUB for 7t/4-DQPSK shall be in accordance with table 9.4. The NUB shall 
be used by MSs to transmit control or traffic messages to the BS. 

Table 9.4: Normal Uplink Burst (NUB) for 7i/4-DQPSK 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 4 


4 


tail bits 


t1 to t4 


see clause 9.4.4.3.5 


5 to 220 


216 


scrambled block 1 bits 


bkn1{^)^obkn1{2■{6) 


see clause 8 


221 to 242 


22 


normal training sequence 


nUo n22or pUo p22 


see clause 9.4.4.3.2 


243 to 458 


216 


scrambled block 2 bits 


bkn2{^) \o bkn2{2-{6) 


see clause 8 


459 to 462 


4 


tail bits 


t1 to t4 


see clause 9.4.4.3.5 


NOTE: All fields shall be sent using 7t/4-DOPSK modulation. 



The allocation of the modulation bits in the NUB for 7t/8-D8PSK shall be in accordance with table 9.5. The NUB shall 
be used by MSs to transmit control or traffic messages to the BS. 

Table 9.5: Normal Uplink Burst (NUB) for 7t/8-D8PSK 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 6 


6 


tail bits -P8 


T1 to T6 


see clause 9.4.4.3.5 


7 to 330 


324 


scrambled block 1 bits 


bkn1{^)^obkn1{324) 


see clause 8 


331 to 363 


33 


normal training sequence-P8 


A/no A/33 or PI to P33 


see clause 9.4.4.3.2 


364 to 687 


324 


scrambled block 2 bits 


bkn2{^ ) to bkn2{324) 


see clause 8 


688 to 693 


6 


tail bits -P8 


T1 to T6 


see clause 9.4.4.3.5 


NOTE: All fields shall be sent using 71/8-D8PSK modulation. 
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9.4.4.2.5 



Normal continuous downlink burst 



The allocation of the modulation bits in the normal continuous downlink 7t/4-DQPSK burst shall be in accordance with 
table 9.6. The normal continuous downlink burst shall be used by the BS in continuous transmission mode to transmit 
control or traffic messages to the MS. 

Table 9.6: Normal continuous downlink burst for 7i/4-DQPSK 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 12 


12 


normal training sequence 3 


q1Uoq22 


see clause 9.4.4.3.2 


13to14 


2 


phase adjustment bits 


haUoha2 


see clause 9.4.4.3.6 


15 to 230 


216 


scrambled block 1 bits 


bkn1{:)\obkn1{2-\6) 


see clause 8 


231 to 244 


14 


scrambled broadcast bits 


bb{^)^obb{■{4) 


see clause 8 


245 to 266 


22 


normal training sequence 


n Ho n22 or pUop22 


see clause 9.4.4.3.2 


267 to 282 


16 


scrambled broadcast bits 


bb{^5)\obb{3Q) 


see clause 8 


283 to 498 


216 


scrambled block 2 bits 


bkn2{■{)^obkn2{2^6) 


see clause 8 


499 to 500 


2 


phase adjustment bits 


hb1 to hb2 


see clause 9.4.4.3.6 


501 to 510 


10 


normal training sequence 3 


qUoqW 


see clause 9.4.4.3.2 


NOTE: All fields shall be sent using 7t/4-DQPSK modulation. 



The allocation of the modulation bits in the normal continuous downlink 7t/8-D8PSK burst shall be in accordance with 
table 9.7. 

Table 9.7: Normal continuous downlink burst for 71/8-D8PSK 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 12 


12 


normal training sequence 3 (see note 1) 


q1Uoq22 


see clause 
9.4.4.3.2 


13to15 


3 


phase adjustment bits (see note 2) 


haUo ha3 


see clause 
9.4.4.3.6 


16 to 339 


324 


scrambled block 1 bits (see note 2) 


bkn1{^) io bkn1 {324) 


see clause 8 


340 to 353 


14 


scrambled broadcast bits (see note 1) 


bb(1) to fc>fc>(14) 


see clause 8 


354 to 386 


33 


normal training sequence-P8 (see note 2) 


NUo N33 or PUo P33 


see clause 
9.4.4.3.2 


387 to 402 


16 


scrambled broadcast bits (see note 1) 


bb(15)toto(30; 


see clause 8 


403 to 726 


324 


scrambled block 2 bits (see note 2 


bkn2{^ ) to bkn2{324) 


see clause 8 


727 to 729 


3 


phase adjustment bits (see note 2) 


hbUohb3 


see clause 
9.4.4.3.6 


730 to 739 


10 


normal training sequence 3 (see note 1) 


q1 \.oq10 


see clause 
9.4.4.3.2 


NOTE 1 : This field shall be sent using 7i/4-DQPSK modulation. 
NOTE 2: This field shall be sent using 71/8-D8PSK modulation. 



9.4.4.2.6 



Synchronization continuous downlink burst 



The allocation of the modulation bits in the synchronization continuous downlink burst shall be in accordance with 
table 9.8. The synchronization continuous downlink burst shall be used by BSs in continuous transmission mode to 
broadcast synchronization messages and to transmit control messages to the MSs. 
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Table 9.8: Synchronization continuous downlinl< burst 



Bit Number 
(BN) 


Field length) 
(bits) 


Field content 


Field bits number 


Definition 


1 to 12 


12 


normal training sequence 3 


q1Uoq22 


see clause 9.4.4.3.2 


13to14 


2 


phase adjustment bits 


hc1 to hc2 


see clause 9.4.4.3.6 


15 to 94 


80 


frequency correction 


f1 to f80 


see clause 9.4.4.3.1 


95 to 214 


120 


scrambled synchronization block 1 bits 


sfc>(1)tosb(120) 


see clause 8 


215 to 252 


38 


synchronization training sequence 


y1 to y38 


see clause 9.4.4.3.4 


253 to 282 


30 


scrambled broadcast bits 


bb{-\) \o bb{30) 


see clause 8 


283 to 498 


216 


scrambled block 2 bits 


bkn2{■{)^obkn2{2^6) 


see clause 8 


499 to 500 


2 


phase adjustment bits 


hd1 to hd2 


see clause 9.4.4.3.6 


501 to 510 


10 


normal training sequence 3 


q1\oq10 


see clause 9.4.4.3.2 


NOTE: All fields shall be sent using 7i/4-DQPSK modulation 



9.4.4.2.7 



Normal discontinuous downlink burst 



The allocation of the modulation bits in the 71/4-DQPSK normal discontinuous downlink burst shall be in accordance 
with table 9.9. The normal discontinuous downlink burst shall be used by BS in timesharing transmission mode to 
transmit control or traffic messages to the MS. 

Table 9.9: Normal discontinuous downlink burst for 71/4-DQPSK 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 2 


2 


normal training sequence 3 


q21 to q22 


see clause 9.4.4.3.2 


3 to 4 


2 


phase adjustment bits 


hg1 to hg2 


see clause 9.4.4.3.6 


5 to 220 


216 


scrambled block 1 bits 


bkn^■{)^obkn^2^6) 


see clause 8 


221 to 234 


14 


scrambled broadcast bits 


bb{^)^obb{^4) 


see clause 8 


235 to 256 


22 


normal training sequence 


nUo n22or pUop22 


see clause 9.4.4.3.2 


257 to 272 


16 


scrambled broadcast bits 


bb{-\5)\obb{30) 


see clause 8 


273 to 488 


216 


scrambled block 2 bits 


bkn2{■{)^obkn2{2^6) 


see clause 8 


489 to 490 


2 


phase adjustment bits 


hhUohh2 


see clause 9.4.4.3.6 


491 to 492 


2 


normal training sequence 3 


q1 to q2 


see clause 9.4.4.3.2 


NOTE: All fields shall be sent using 7t/4-DOPSK modulation 



The allocation of the modulation bits in the 71/8-D8PSK normal discontinuous downlink burst shall be in accordance 
with table 9.10. 

Table 9.10: Normal discontinuous downlink burst for 71/8-D8PSK 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 2 


2 


normal training sequence 3 (see note 1) 


q21 to q22 


see clause 9.4.4.3.2 


3 to 5 


3 


phase adjustment bits (see note 2) 


hg1 to hg3 


see clause 9.4.4.3.6 


6 to 329 


324 


scrambled block 1 bits (see note 2) 


bkn1{-{)\obkn1 {324) 


see clause 8 


330 to 343 


14 


scrambled broadcast bits (see note 1 ) 


bb{^)\obb{U) 


see clause 8 


344 to 376 


33 


normal training sequence-P8 (see note 2) 


N1 to N33 or PUo P33 


see clause 9.4.4.3.2 


377 to 392 


16 


scrambled broadcast bits (see note 1 ) 


bb[^5)\obb{3Q) 


see clause 8 


393 to 716 


324 


scrambled block 2 bits (see note 2) 


bkn2{\)\obkn2{324) 


see clause 8 


717 to 719 


3 


phase adjustment bits (see note 2) 


hhUohh3 


see clause 9.4.4.3.6 


720 to 721 


2 


normal training sequence 3 (see note 1) 


q1 to q2 


see clause 9.4.4.3.2 


NOTE 1 : This field shall be sent using jt/4-DQPSK modulation. 
NOTE 2: This field shall be sent using J1/8-D8PSK modulation. 



ETSI 



152 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



9.4.4.2.8 



Synchronization discontinuous downlink burst 



The allocation of the modulation bits in the synchronization discontinuous downlink burst shall be in accordance with 
table 9. 11. The synchronization discontinuous downlink burst shall be used by the BS in timesharing transmission mode 
to broadcast synchronization messages and to transmit control messages to the MS. 

Table 9.1 1 : Synchronization discontinuous downlinit burst 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 2 


2 


normal training sequence 3 


q21 to q22 


see clause 9.4.4.3.2 


3 to 4 


2 


phase adjustment bits 


hi1 to hi2 


see clause 9.4.4.3.6 


5 to 84 


80 


frequency correction 


f1 to f80 


see clause 9.4.4.3.1 


85 to 204 


120 


scrambled synchronization block 1 bits 


sb(1)tosfc>(120) 


see clause 8 


205 to 242 


38 


synchronization training sequence 


y1 to y38 


see clause 9.4.4.3.4 


243 to 272 


30 


scrambled broadcast bits 


bb{^) \o bb{30) 


see clause 8 


273 to 488 


216 


scrambled block 2 bits 


bkn2{^) \o bkn2{2-{6) 


see clause 8 


489 to 490 


2 


phase adjustment bits 


hj1 to hj2 


see clause 9.4.4.3.6 


491 to 492 


2 


normal training sequence 3 


q1 to q2 


see clause 9.4.4.3.2 


NOTE: All fields shall be sent using 7i/4-DQPSK modulation. 



9.4.4.3 



Burst fields 



9.4.4.3.1 Frequency correction field 

The frequency correction field shall contain 80 bits: 

(fl,f2, ,^) = (1, 1,...., 1) 

(f9,fl0,....,f72) = (0,0,....,0) 
(f73,,f74,...,fS0) = (1,1, --A) 



(9.1) 
(9.2) 
(9.3) 



The frequency correction field generates an un-modulated carrier at 2,25 kHz above the nominal carrier frequency, 
preceded and followed by a short period (4 symbol durations) of un-modulated carrier at 6,75 kHz below the nominal 
carrier frequency. 



9.4.4.3.2 



Normal training sequence 



Three 22 bit normal training sequences are defined for 7t/4-DQPSK modulation. 

The first two 7t/4-DQPSK normal training sequences shall be used on the jt/4-DQPSK normal uplink and downlink 
bursts. The type of training sequence shall be used as a flag indicating the presence of one or two logical channels on 
the blocks 1 and 2 of the burst, according to table 9.12. 

Table 9.12: Training sequence mapping to logical channels 



Normal training sequence 


Logical channel 


1 


TCH 
SCH/F 


2 


STCH + TCH 

STCH + STCH 

SCH/HD + SCH/HD 

SCH/HD + BNCH 



The third 7t/4-DQPSK training sequence shall be a supplementary training sequence spread over two consecutive 
downlink bursts. 



The 7t/4-DQPSK normal training sequence 1 shall be: 

(nl, n2,..., n22) = (1,1, 0,1, 0,0, 0,0, 1,1, 1,0, 1,0, 0,1, 1,1, 0,1, 0,0) 



(9.4) 
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The 7t/4-DQPSK normal training sequence 2 shall be: 

{pi, p2,..., p22) = (0,1, 1,1, 1,0, 1,0, 0,1, 0,0, 0,0, 1,1, 0,1, 1,1, 1,0) (9.5) 

The 7t/4-DQPSK normal training sequence 3 shall be: 

(ql, q2,..., q22) = (1,0, 1,1, 0,1, 1,1, 0,0, 0,0, 0,1, 1,0, 1,0, 1,1, 0,1) (9.6) 

Two 33 bit normal training sequences are defined for 7t/8-D8PSK. 

The 7t/8-D8PSK normal training sequences shall be used on the 7t/8-D8PSK normal uplink and downlink bursts. The 
type of training sequence shall be used as a flag indicating the presence of one or two logical channels on the blocks 1 
and 2 of the burst, according to table 9.13. 

Table 9.13: Training sequence mapping to logical channels for 71/8-D8PSK 



Normal training sequence 


Logical channel 


1 


SCH-P8/F 


2 


SCH-P8/HD + SCH-P8/HD 



The normal training sequence 1-P8 shall be: 

(Nl, N2,..., N33) = (1,1,1, 0,0,1, 1,0,1, 1,1,1, 0,0,0, 1,1,1, 1,0,0, 0,1,1, 1,1,0, 0,0,0, 0,0,0) (9.7) 

The normal training sequence 2-P8 shall be: 

(PI, P2,..., P33) = (1,0,1, 0,1,1, 1,1,1, 1,0,1, 0,1,0, 1,0,1, 1,1,0, 0,0,1, 1,0,0, 0,1,0, 0,1,0) (9.8) 

On a 7t/8-D8PSK channel, receivers determine whether a slot contains a 7t/4-DQPSK normal uplink or downlink burst 
or a 7t/8-D8PSK normal uplink or downlink burst by determining whether normal training sequence 1 or normal training 
sequence 2 uses the 7t/4-DQPSK form or the 7t/8-D8PSK form. 

9.4.4.3.3 Extended training sequence 

The extended training sequence for n/4 -DQPSK shall be a 30 bit synchronization word used for the uplink control 
burst. 

The extended training sequence for 7t/4-DQPSK shall be: 

(xl, x2,..., x30) = (1,0, 0,1, 1,1, 0,1, 0,0, 0,0, 1,1, 1,0, 1,0, 0,1, 1,1, 0,1, 0,0, 0,0, 1,1) (9.9) 

The extended training sequence for 7t/8-D8PSK shall be a 45 bit synchronization word used for the uplink control burst. 

The extended training sequence for 7t/8-D8PSK shall be: 

(Xl, X2,..., X45) = (0,1,1,1,0,0,1,1,0,1,0,0,0,0,1,0,0,0,1,1,1,0,1,1,0,1,0,1,0,1,1,1,1,1,0,1,0,0,0,0,0,1,1,1,0) (9.10) 

On a D8PSK channel, receivers determine whether a subslot contains a 7t/4-DQPSK control uplink burst or a 
7t/8-D8PSK control uplink burst by determining whether the extended training sequence uses the 7t/4-DQPSK form or 
the 7t/8-D8PSK form. 

9.4.4.3.4 Synchronization training sequence 

The synchronization training sequence shall be a 38 bit synchronization word used for the synchronization downlink 
burst. 

The synchronization training sequence shall be: 

(y7, 3;2,..., y5S) = (l,l,0,0, 0,0, 0,1, 1,0,0,1, 1,1,0,0, 1,1, 1,0, 1,0,0,1, 1,1,0,0,0,0,0,1, 1,0,0,1, 1,1) (9.11) 
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9.4.4.3.5 



Tail bits 



The tail bit field for 7i/4-DQPSK shall contain 4 bits used for reducing the effect of filter transient response at the 
beginning and end of the bursts and for equalization purposes. 



The contents of the Jt/4-DQPSK tail bit field shall be: 

{tl, a, t3, f4) = (l, 1,0, 0) 



(9.12) 



The tail bit field for 7t/8-D8PSK shall contain 6 bits used for reducing the effect of filter transient response at the 
beginning and end of the bursts. 



The contents of the 7t/8-D8PSK tail bit field shall be: 

(T],T2, ... T6) = (l, 1, 1,0,0,0) 



(9.13) 



9.4.4.3.6 



Phase adjustment bits 



The 71/4-DQPSK phase adjustment bits shall be used on the 7t/4-DQPSK bursts defined in clauses 9.4.4.2 and 9.4.5.3 to 
provide a known phase relationship between the different training sequences of the burst, whatever is the content of the 
blocks. 

The value of the pair of phase adjustment bits shall be set so that the phase shift D^ they generate (see clause 5) is equal 
to: 



n2 
n=n1 



(9.14) 



Where D^n) is the phase transition generated by the bits BN(2ti-l), BN(2n)), nl and n2 are given by table 9.14 for 
jt/4-DQPSK. 

Table 9.14: 7i/4-DQPSK Phase adjustment bits 



phase adjustment bits 


n1 


n2 


(ha1, ha2) 


8 


122 


(hb1, hb2) 


123 


249 


(hc1, hc2) 


8 


108 


(hd1, hd2) 


109 


249 


(he1, he2) 


112 


230 (see note) 


(hf1, hf2) 


1 


111 


(hg1, hg2) 


3 


117 


(hh1, hh2) 


118 


244 


(hi1, hi2) 


3 


103 


(hj1. hj2) 


104 


244 


NOTE: The n2 value 230 does not include the second symbol of the tail in the 
phase balance causing a non-zero phase change. 



The 7t/8-D8PSK phase adjustment bits shall be used on the 7t/8-D8PSK bursts defined in clauses 9.4.4.2 and 9.4.5.3 to 
provide a known phase relationship between the different training sequences of the burst, whatever the content of the 
blocks. The value of the three phase adjustment bits shall be set so that the phase shift D^they generate (see clause 5) is 
equal to a phase as defined by equation 9.14 or 9.15 (see table 9.15). 



Z)^ = -£D^(n) + f 



(9.15) 



n=n\ 



Where D^n) is the phase transition generated by the bits BN(3n-2), BN(3n-l), BN(3n)), nl and n2 are given by 
table 9.15 for 7t/8-D8PSK. 
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Table 9.15: Phase adjustment bits for 7t/8-D8PSK 



phase adjustment bits 


n1 


n2 


(ha1 ,ha2,ha3) 


8 


1 22 (see note 1 ) 


(hb1,hb2,hb3) 


123 


249 (see note 2) 


(he1,he2,he3) 


111 


231 (see note 1) 


(hf1,hf2,hf3) 


1 


1 1 (see note 1 ) 


(hg1,hg2,hg3) 


3 


1 1 7 (see note 1 ) 


(hh1,hh2,hh3) 


118 


244 (see note 2) 


NOTE 1 : In this case, 00 has a resultant phase shift of 7t/8 (see expressions. 15). 
NOTE 2: In this case, 00 has a resultant phase shift of (see expression 9.14). 



9.4.5 Transmission modes for piiase modulation 



9.4.5.1 



BS continuous transmission 



When the BS is in continuous transmission mode normal downlink bursts or synchronization bursts shall be transmitted 
on all unused downlink slots of the main carrier and may be transmitted on the unallocated physical channels of the 
other carriers. 

On the main carrier the BS shall only be allowed to ramp down and up during a BLCH. On the other carriers the BS 
may ramp down and up during the slots of an UP channel. 

The first burst after ramp up of a D-CT shall be preceded by a start burst (SNmax = 5), according to table 9.16. 

Table 9.16: Start burst 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 10 


10 


normal training sequence 3 


q1 \.oq10 


clause 9.4.4.3.2 



The last burst before ramp down of a D-CT shall be followed by a stop burst (SNmax = 6), according to table 9. 17. 

Table 9.17: stop burst 



Bit Number 
(BN) 


Field length 
(bits) 


field content 


field bits number 


definition 


1 to 12 


12 


normal training sequence 3 


q1Uoq22 


clause 9.4.4.3.2 



9.4.5.2 



BS timesharing transmission 



The BS in timesharing transmission mode need not to ramp down and up between adjacent discontinuous downlink 
bursts. In the case where the BS does not perform the ramping, the discontinuous burst shall be followed by 4 symbols 
(corresponding to the guard period) according to table 9.18, and the subsequent burst shall be preceded by 5 symbols 
(corresponding to the ramp up and linearization period) according to table 9.19. 

Table 9.18: Bits following the burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 8 


8 


normal training sequence 3 


q3\.oq10 


clause 9.4.4.3.2 



Table 9.19: Bits preceding the burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 10 


10 


normal training sequence 3 


q1Uoq20 


clause 9.4.4.3.2 
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9.4.5.3 



MS multiple slot transmission 



The MS transmitting on more than 1 physical channel need not to ramp down and up between adjacent normal uplink 
bursts. In the case where the MS does not perform the ramping, the burst shall be followed by 7 symbols (corresponding 
to the guard period) defined in table 9.20 for 7t/4-DQPSK and in table 9.22 for 7t/8-D8PSK, the subsequent burst shall 
be preceded by 17 symbols (corresponding to the ramp up and linearization period), according table 9.21 for 
71/4-DQPSK and table 9.23 for ji/8-D8PSK. 

Table 9.20: Bits following a 7t/4-DQPSK burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 2 


2 


phase adjustment bits 


he1\ohe2 


clause 9.4.4.3.6 


3 to 4 


2 


tail bits 


T1 to t2 


clause 9.4.4.3.5 


5 to 14 


10 


normal training sequence 3 


QUoqW 


clause 9.4.4.3.2 



Table 9.21 : Bits preceding a 7t/4-DQPSK burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 30 


30 


extended training sequence 


x1 to x30 


Clause 9.4.4.3.3 


31 to 32 


2 


tail bits 


t3\o t4 


Clause 9.4.4.3.5 


33 to 34 


2 


phase adjustment bits 


hf1 to hf2 


Clause 9.4.4.3.6 



Table 9.22: Bits following a 71/8-D8PSK burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 3 


3 (see note 2) 


phase adjustment bits 


he1 \.o he3 


clause 9.4.4.3.6 


4 to 5 


2 (see note 1 ) 


tail bits 


t1 to t2 


clause 9.4.4.3.5 


etois 


10 (see note 1) 


normal training sequence 3 


q1\oq10 


clause 9.4.4.3.2 


NOTE 1 : This field shall be sent using 7i/4-DQPSK modulation. 
NOTE 2: This field shall be sent using 7t/8-D8PSK modulation. 



Table 9.23: Bits preceding a 7t/8-D8PSK burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 30 


30 (see note 1 ) 


extended training sequence 


x1 to x30 


Clause 9.4.4.3.3 


31 to 32 


2 (see note 1 ) 


tail bits 


t3\ot4 


Clause 9.4.4.3.5 


33 to 35 


3 (see note 2) 


phase adjustment bits 


hf1 to hf3 


clause 9.4.4.3.6 


NOTE 1 : This field shall be sent using 7t/4-DQPSK modulation. 
NOTE 2: This field shall be sent using 7t/8-D8PSK modulation. 



9.4.6 Types of physical channels for QAM 

In QAM channels, two types of physical channel are defined: 

• the Control Physical (CP) Channel; and 

• the Unallocated Physical channel. 

9.4.6.1 CP channel 

The CP channel is a physical channel carrying exclusively CCH. 
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9.4.6.2 UP channel 

The UP channel is a physical channel not allocated to one or more MS. 

9.4.7 Bursts for QAM 

9.4.7.1 General 

A burst is a period of RF carrier that is modulated by a data stream. A burst therefore represents the physical content of 
a timeslot or subslot. 

9.4.7.2 Modulation symbol numbering 

A timeslot shall be divided into 34 QAM modulation symbol durations, each one with a duration of 5/12 ms 
(approximately 416,6 |is). A particular modulation symbol within a burst shall be referenced by a Symbol Number (SN), 
with the first modulation symbol numbered SNl and the last modulation symbol numbered SNmax. 

Different types of bursts are defined, having different durations. The content of the burst is defined in terms of 
modulation symbols. Each modulation symbol is composed of several sub-carrier symbols (see clause 5.10). Sub-carrier 
symbols (SS) within a burst shall be referenced by two indices and shall be denoted as SS(i,j), the first index / being a 
time index numbered from 1 to N and the second index y being the sub-carrier index from to M-1, where M is the 
number of sub-carriers. The relation between sub-carrier index and its frequency is defined in clause 5. 

Sub-carrier symbols can be either data sub-carrier symbol (Dx), synchronization sub-carrier symbols (Sx), pilot 
sub-carrier symbols (Px), header sub-carrier symbols (Hx), or zeroed sub-carrier symbols (Zx). 

9.4.7.3 Modulation bit numbering 

Only data sub-carrier symbols convey information bits. The number of bits in each data sub-carrier symbol is a function 
of the QAM constellation used. 

The number of information bits in a burst is also a function of the burst type. A particular modulation bit within a burst 
shall be referenced by a Bit Number (BN), with the first modulation bit numbered BNl and the last modulation bit 
numbered BNmax. 

At the modulator, the modulation bits shall be grouped according to the constellation used. For 4-QAM, they shall be 
grouped in pairs of consecutive numbered bits. For 16-QAM, they shall be grouped in sets of four consecutive 
numbered bits. For 64-QAM, they shall be grouped in sets of six consecutive numbered bits. Each group shall be 
converted into one modulation symbol as described in clause 5.4. 

The mapping of information bits into data sub-carrier symbols for all burst types is presented in clause 5.5. 

9.4.7.4 Burst timing 

The symbol time is defined as the instant at which the transmitted symbol waveform is at a maximum for the symbol of 
interest. The timing of a modulation symbol is determined by its symbol time. 

The symbol time of the modulation symbol SN(n) shall be delayed by (n+d-1) modulation symbol durations with 
respect to the start of the slot, with: 

• n: integer (1 ... (SNmax)); 

• d: is defined as the burst delay. The burst delay represents the delay between the start of the timeslot and the 
symbol time of the symbol SNl. The burst delay shall be expressed in modulation symbol duration and varies 
with the type of burst and the SSN. The values of the burst delays are given in table 9.24. 
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9.4.8 Type of bursts for QAM 
9.4.8.1 General 

Six types of QAM bursts shall exist in the system. Figure 9.4 summarizes the description of the bursts and their timing 
with respect to the timeslot. 
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Figure 9.4: Types of bursts for QAM 
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NOTE: The power-time mask is defined in clause 6.4.10, figure 6.5 and table 6.20. The ti period defined in 
clause 6.4.10, table 6.20 may be used for ramping and PA linearization. 

Table 9.24: Burst types for QAM 



Burst type 


SNmax 


c/ burst delay (in symbol duration) 


Symbol allocation 






SSN1 


SSN2 




Control uplink 


14 


2 


19 


See clause 9.4.8.2.1 


Random access uplink 


14 


2 


19 


See clause 9.4.8.2.2 


Linearization uplink 


not applicable 


not applicable 


not allowed 


See clause 9.4.8.2.3 


Normal uplink 


31 


2 


See clause 9.4.8.2.3 


Normal downlink 


34 





See clause 9.4.8.2.4 


Linearization downlink 


34 





See clause 9.4.8.2.5 



9.4.8.2 



Modulation symbols allocation 



The bursts are composed of sub-carrier symbol sets containing symbols of the same modulation type. When considered 
together, the sets compose either a valuable information for a proper operation of the physical layer or carry logical 
channel information. 

The sub-carrier symbol sets used with QAM modulation are sync sequence set, pilots set, header set, data set, filler set 
and zeroed symbols set. 

Sync sequence set, pilot set and filler set use symbols that lie in the unit circle of the constellation as described in 
clause 5.13. The header set uses only 4-QAM modulation sub-carrier symbols. The zeroed set use symbols whose 
magnitude is equal to zero. The data set may use any 4-QAM, 16-QAM or 64-QAM modulation sub-carrier symbols. 

The sub-carrier symbol sets are described in clause 9.4.8.3. 

The allocation of the sub-carrier symbols and their content for each of the six types of QAM burst shall be as defined in 
clauses P. 1.1 to P. 1.6. However, note that the linearization uplink burst (LB) contains no useful symbols and its timing 
shall only be determined by the time mask (see clause 6.4.10). 



9.4.8.3 



Burst sub-carrier symbol sets 



9.4.8.3.1 



General on burst sub-carrier symbol sets 



All of the sub-carrier symbol sets in the clauses 9.4.8.3.2 to 9.4.8.3.8 have been defined such that the sub-carrier 
frequency domain multiplexers will all start at phase radians, att=tQ=Q, at the beginning of each burst, where Iq is 
shown in figures 5.8. This includes bursts transmitted in SubSlot Number 2. This makes their definition independent of 
the waveform filter. 

In a physical implementation, the defined sub-carrier symbols should be pre-rotated to compensate for the delay through 
the transmit symbol waveform g(t) in order to maintain proper phasing. For example, a filter with delay tj should rotate 
each sub-carrier symbol by -27tf^t^ radians, where /„ is the sub-carrier frequency and tg is the time delay through the 
symbol waveform g(t) prior to modulation to insure that proper phasing of the sub-carrier frequency domain 
multiplexers is achieved. 

9.4.8.3.2 Uplink sync sequence set 

The Uplink Sync sequence Sets contain 2M sub-carrier symbols where M is the number of sub-carriers used. 

They are denoted USSx, where x is the number of sub-carriers. For example, USS8 denotes the Uplink Sync Sequence 
Set in the case of 8 sub-carriers. 

The amplitude of the symbols is as described in clause 5.13. The symbol waveform filter independent phases are 
defined as a multiple of ti radians. 

The values of the phases shall be as expressed in clause P.2.1. 
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The USSx are used in all control uplink bursts and normal uplink bursts of the corresponding number of sub-carriers x. 
USS8 is used in the Random Access burst. 

9.4.8.3.3 Downlink sync sequence set 

The Downlink sync Sequence Sets contain 1.5M sub-carrier symbols where M is the number of sub-carriers used. 

They are denoted DSSx, where x is the number of sub-carriers. For example, DSS8 denotes the Downlink Sync 
Sequence Set in the case of 8 sub-carriers. 

The amplitude of the symbols is as described in clause 5.13. The symbol waveform filter independent phases are 
defined as a multiple of n radians. 

The values of the phases shall be as expressed in clause P. 2.2. 

The DSSx are used in all normal downlink bursts and in the linearization downlink bursts of the corresponding number 
of sub-carriers x. 

9.4.8.3.4 Half-slot uplink pilots set 

The Half-slot Uplink Pilots Set contain 1.5M sub-carrier symbols where M is the number of sub-carriers used. 

They are denoted HUPSx, where x is the number of sub-carriers. For example, HUPS8 denotes the Half-slot Uplink 
Pilots Set in the case of 8 sub-carriers. 

The amplitude of the symbols is as described in clause 5.13. The symbol waveform filter independent phases are 
defined as a multiple of n radians. 

The values of the phases shall be as expressed in clause P. 2. 3. 

The HUPSx are used in all control uplink bursts of the corresponding number of sub-carriers x. HUPS8 is used in the 
Random Access burst. 

9.4.8.3.5 Full-slot uplink pilots set 

The Full-slot Uplink Pilots Set contains 3M sub-carrier symbols where M is the number of sub-carriers used. 

They are denoted FUPSx, where x is the number of sub-carriers. For example, FUPS8 denotes the Full-slot Uplink 
Pilots Set in the case of 8 sub-carriers. 

The amplitude of the symbols is as described in clause 5.13. The symbol waveform filter independent phases are 
defined as a multiple of n radians. 

The values of the phases shall be as expressed in clause P. 2.4. 

The FUPSx are used in all normal uplink bursts of the corresponding number of sub-carriers x. 

9.4.8.3.6 Full-slot downlink pilots set 

The Full-slot Downlink Pilots Set contain 3M sub-carrier symbols where M is the number of sub-carriers used. 

They are denoted FDPSx, where x is the number of sub-carriers. For example, FDPS8 denotes the Full-slot Downlink 
Pilots Set in the case of 8 sub-carriers. 

The amplitude of the symbols is as described in clause 5.13. The symbol waveform filter independent phases are 
defined as a multiple of ti radians. 

The values of the phases shall be as expressed in clause P. 2.5. 

The FUPSx are used in all normal downlink bursts of the corresponding number of sub-carriers x. 
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9.4.8.3.7 Filler sets 



Two different filler sets are defined. Filler Set A is used in the Linearization Downlink Burst as shown in clause P. 1 .6 
and when a NUB is appended to a second NUB or to a CUB. In the latter case, Filler Set A is appended to the end of the 
first NUB. Filler Set B is used when a CUB is concatenated with a second CUB or a NUB, and is appended to the end 
ofthe first CUB. 

The Filler Sets contains 3M sub-carrier symbols where M is the number of sub-carriers used. 

They are denoted FiSQx, where Q can be equal to A or B and x is the number of sub-carriers. For example, FiSA8 
denotes the Filler Set A used, for example, in the LDB in the case of 8 sub-carriers. 

The amplitude ofthe symbols is as described in clause 5.13. The symbol waveform filter independent phases are 
defined as a multiple of n radians. 

The values ofthe phases shall be as expressed in clause P. 2. 6. 

The FiSAx are used in all linearization downlink bursts. 

The MS transmitting on more than 1 slot need not to ramp down and up between adjacent normal uplink bursts. In the 
case where the MS does not perform the ramping, the burst shall be followed by 3 filler symbols (FiSA or FiSB, 
depending on the particular concatenation) corresponding to the guard period (total of 3M sub-carrier symbols, where 
M is the number of sub-carriers) defined in clause P. 2. 6. 

9.4.8.3.8 Linearization downlink zeroed set 

The linearization downlink zeroed set is a set of sub-carrier symbols whose magnitude is equal to zero. The number of 
sub-carrier symbols in the set is equal to 2,5M where M is the number of sub-carriers. 

They are denoted LZSx, where x is the number of sub-carriers. For example, LZS8 denotes the Linearization downlink 
Zeroed Set in the case of 8 sub-carriers. 

LZS8 is composed of sub-carrier symbols Zl to Z20. LZS16 is composed of sub-carrier symbols Zl to Z40. LZS32 is 
composed of sub-carrier symbols Zl to Z80. LZS48 is composed of sub-carrier symbols Zl to Z120, see clause P. 1.6. 

9.4.9 Transmission modes for QAM 

9.4.9.1 BS transmission 

For QAM modulation, only BS continuous transmission is supported. 

9.4.9.2 MS multiple slot transmission 

The MS transmitting on more than 1 physical channel need not to ramp down and up between adjacent normal uplink 
bursts. In the case where the MS does not perform the ramping, the burst shall be followed by 3 filler symbols (FiSA or 
FiSB, depending on the particular concatenation) corresponding to the guard period (total of 3M sub-carrier symbols, 
where M is the number of sub-carriers) defined in clause P. 2. 6. 

9.5 Mapping of logical channels into physical channels 

Clauses 9.5.1 to 9.5.5 apply to phase modulation and clauses 9.5.6 to 9.5.10 to QAM. 
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9.5.1 General mapping of logical channels into 7r/4-DQPSK physical 
channels 

TC/4-DQPSK physical channels use 7i/4-DQPSK bursts. 7i/4-DQPSK bursts use 7i/4-DQPSK modulation. Table 9.25 
defines the mapping in time of logical channels into 7t/4-DQPSK physical channel types. 

Table 9.25: Mapping of logical channels into 7i/4-DQPSK physical channels 



Logical 
channel 


Dire- 
ction 


Burst 
type 


SSN/ 
Block 


Physical 
channel 


FN 


TN 


BSCH 


DL 


SB 


BKN1 
BKN1 


CP, TP 
UP 


18 
1...18 


4-(MA/+1)mod4# 
1...4 


BNCH 


DL 


NDB 

NDB 

SB 


BKN2 
BKN2 
BKN2 


CP,TP 
CP 
UP 


18 
1...18 
1...18 


4-(/WA/+3)mod4# 
1...4 
1...4 


AACH 


DL 


NDB, SB 


BBK 


CP, TP, UP 


1...18 


1...4# 


BLCH 


DL 


NDB,SB 


BKN2 


CP, UP 

TP 


1...18 
18 


1...4 
1...4 


CLCH 


UL 


LB 


SSN1 
SSN1 


CP, TP 
CP, UP 


18 
1...18 


4-(/WA/+1)mod4# 
1...4 


SCH/F 


DL 


NDB 


BKN1+BKN2 


CP 

TP 


1...18 
18 


1...4 
1...4 


UL 


NUB 


BKN1+BKN2 


CP 

TP 


1...18 
18 


1...4 
1...4 


SCH/HD 


DL 


NDB, SB 


BKN1, BKN2 


CP, UP 
TP 


1...18 
18 


1...4 
1...4 


SCH/HU 


UL 


CB 


SSN1, SSN2 


CP 

TP 


1...18 
18 


1...4 
1...4 


TCH 


DL 


NDB 


BKN1, BKN2 


TP 


1...17 


1...4 


UL 


NUB 


BKN1, BKN2 


TP 


1...17 


1...4 


STCH 


DL 


NDB 


BKN1, BKN2 


TP 


1...17 


1...4 


UL 


NUB 


BKN1, BKN2 


TP 


1...17 


1...4 


NOTE: # indicates a mandatory mapping. 



The mapping for 7t/4-DQPSK TP and CP physical channels shall be as summarized in tables 9.26 and 9.27. 
Table 9.26: TDMA frame mapping on 7i/4-DQPSK TP channel 



Frame 
FN 


DOWNLINK 


UPLINK 1 


Block BKN1 


Block BKN2 


Subslot SSN1 
or Block BKN1 


Subslot SSN2 
or Block BKN2 


1 to17 


TCH 

STCH + TCH 

STCH + STCH 


TCH 
STCH + TCH 
STCH + STCH 


18 


SC 
SCH/HD 

BSCH 
SCH/HD 


H/F 

SCH/HD 

SCH/HD 

BNCH 


SC 
SCH/HU 
CLCH 


H/F 

SCH/HU 
SCH/HU 



Table 9.27: TDMA frame mapping on 7i/4-DQPSK CP channel 



Frame 
FN 


DOWNLINK 


UPLINK 1 


Block BKN1 


Block BKN2 


Subslot SSN1 
or Block BKN1 


Subslot SSN2 
or Block BKN2 


1 to 18 


SC 
SCH/HD 
SCH/HD 


H/F 

SCH/HD 
BNCH 


SC 
SCH/HU 
CLCH 


H/F 

SCH/HU 
SCH/HU 


18 


BSCH 


SCH/HD 







In all cases the AACH shall be mapped onto the broadcast block of each downlink slot. On the downlink the BLCH 
may replace the SCH/HD of the block BKN2. 
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9.5.1a General mapping of logical channels into D8PSK physical channels 

D8PSK is the general name for a channel that allows both 7t/4-DQPSK and 71/8-D8PSK bursts. 7i/4-DQPSK bursts use 
7I/4-DQPSK modulation. 71/8-D8PSK bursts use both 3i/4-DQPSK modulation and 31/8-D8PSK modulation, as defined in 
clause 9.4.4.2. The transmitter may send a 7i/4-DQPSK burst or a 31/8-D8PSK burst independently of the preceding type 
of burst. The uplink and downlink burst types are chosen independently. 

Table 9.28 defines the mapping in time of logical channels within a D8PSK physical channel. 

Table 9.28: Mapping of logical channels into D8PSK physical channels 



Logical 
channel 


Direction 


Burst 
type 


SSN/ 
Block 


Physical 
channel 


FN 


TN 


BSCH 
BNCH 


DL 
DL 


SB (7t/4-DQPSK) 
NDB (7t/4-DQPSK) 
NDB (71/4-DQPSK) 


BKN1 
BKN2 
BKN2 


CP 
CP 
CP 


18 

18 

1...18 


4-(/WA/+1)mod4# 

4-(/WA/+3)mod4# 

1...4 


AACH 


DL 


NDB (71/4-DQPSK) 

NDB (7t/8-D8PSK) (see note 2) 

SB (71/4-DQPSK) 


BBK 


CP 


1...18 


1...4# 


BLCH 


DL 


NDB, SB (7t/4-DQPSK) 
NDB (71/8-D8PSK) 


BKN2 


CP 


1...18 


1...4 


CLCH 


UL 


LB 


SSN1 
SSN1 


CP 
CP 


18 
1...18 


4-(MA/+1)mod4# 
1...4 


SCH/F 


DL 


NDB (71/4-DQPSK) 


BKN1+BKN2 


CP 


1...18 


1 


..4 


UL 


NUB (71/4-DQPSK) 


BKN1+BKN2 


CP 


1...18 


1 


..4 


SCH-P8/F 


DL 


NDB (71/8-D8PSK) 


BKN1+BKN2 


CP 


1...18 


1 


..4 


UL 


NUB (71/8-D8PSK) 


BKN1+BKN2 


CP 


1...18 


1 


..4 


SCH/HD 


DL 


NDB, SB (7t/4-DQPSK) 


BKN1, BKN2 


CP 


1...18 


1 


..4 


SCH-P8/HD 


DL 


NDB (71/8-D8PSK) 


BKN1, BKN2 


CP 


1...18 


1 


..4 


SCH/HU 


UL 


CB (7t/4-DQPSK) 


SSN1, SSN2 


CP 


1...18 


1 


..4 


SCH-P8/HU 


UL 


CB (7t/8-D8PSK) 


SSN1, SSN2 


CP 


1...18 


1 


..4 


NOTE 1 : # indicates a mandatory mapping. 

NOTE 2: Transmitted using 7t/4-DQPSK modulation in a 71/8-D8PSK burst. 



The mapping of TDMA frames onto D8PSK physical channels shall be as summarized in table 9.29. 

Table 9.29: TDMA frame mapping on D8PSK channel 



Frame 
FN 


DOWNLINK 


UPLINK 1 


Block BKN1 


Block BKN2 


Subslot SSN1 


Subslot SSN2 








or Block BKN1 


or Block BKN2 


1 to 18 


SCH/F 


SCH/F 




SCH-P8/F 


SCH-P8/F 


SCH/HD 


SCH/HD 


SCH/HU 


SCH/HU 




SCH-P8/HD 


SCH-P8/HD 


SCH-P8/HU 


SCH-P8/HU 




SCH/HD 


BNCH 


SCH/HU 

SCH-P8/HU 

CLCH 

CLCH 


SCH-P8/HU 
SCH/HU 
SCH/HU 

SCH-P8/HU 


18 


BSCH 


SCH/HD 







In all cases the AACH shall be mapped onto the broadcast block of each downlink slot. On the downlink the BLCH 
may replace the SCH/HD or SCH-P8/HD of the block BKN2. 
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9.5.1b General mapping of logical channels into unallocated physical 
channels for phase modulation 

Unallocated physical channels shall use 7i/4-DQPSK bursts. The mapping shall be as summarized in table 9.30. 
Table 9.30: TDMA frame mapping on unallocated physical channel 



Frame 
FN 


DOWNLINK 


UPLINK 1 


Block BKN1 


Block BKN2 


Subslot SSN1 


Subslot SSN2 


1 to 18 


SCH/HD 
BSCH 


SCH/HD 
BNCH 


CLCH 





The AACH shall be mapped onto the broadcast block of each downlink slot. On the downlink the BLCH may replace 
the SCH/HD of the block BKN2. 

9.5.2 Mapping of BCCH and CLCH for phase modulation 

The BCCH and CLCH shall be mapped on the control frame of 7t/4-DQPSK and 7t/8-D8PSK CP and TP channels. 
BCCH shall be transmitted within a 7t/4-DQPSK burst. 

Table 9.31 : Mapping of the BCCH onto the control frame 



Multiframe 


Frame 
FN18 


Timeslot 


TN1 


TN2 


TN3 


TN4 


(MN}mo6 4 = 1 


downlink BKN1 




BSCH 






downlink BKN2 








BNCH 


uplink SSN1 




CLCH 






{MN}mo6 4 = 2 


downlink BKN1 


BSCH 








downlink BKN2 






BNCH 




uplink SSN1 


CLCH 








{MN)mo6 4 = 3 


downlink BKN1 








BSCH 


downlink BKN2 




BNCH 






uplink SSN1 








CLCH 


{MN)mo6 4 =0 


downlink BKN1 






BSCH 




downlink BKN2 


BNCH 








uplink SSN1 






CLCH 





The mapping of the BCCH and CLCH on the control frame shall be a function of the time slot and multiframe numbers 
and shall be obtained from the following algorithms or from table 9.31. 

• Down-link: 

BNCH mapped if: 

FN =12. and (MN + TN)mod 4 = 1 (9. 16) 
BSCH mapped if: 

FN =12. and (MN + TN)mod 4 = 3 (9. 17) 

• Up-link: 

CLCH mapped if: 

FN= 18 and (MN + TN)mod 4 = 3 (9.18) 
The BSCH shall always be transmitted on a synchronization burst. 

NOTE: Downlink slots for which FN = 18 and (MN + 77V) mod 4 = 1 or 3 are sent using n/4-DQPSK modulation. 
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In addition to this mapping the BS may map the CLCH onto the up-link subslot 1 and the BNCH on the downlink 
block 2 of a CP channel. The mapping shall be performed on a slot to slot basis. The mapping of the CLCH shall be 
indicated on the AACH. 

A MS may linearize its transmitter at any CLCH occurrence, even from another physical channel, provided this does 
not violate other mapping rules. The number of MS transmitter linearizations on one carrier is limited to once per 
multiframe period. 

The BLCH may be mapped onto block 2 of the downlink slots, when a SCH/HD, SCH-P8/HD or a BSCH is mapped 
onto block L The number of BLCH occurrences on one carrier shall not exceed one per 4 multiframe periods. 

At initial power-on of an RF carrier, the BS may linearize its transmitter using the BLCH. In this case the BLCH is 
mapped on a burst similar to the downlink linearization burst, but with an unspecified duration preceding the start burst. 

Slots of an unallocated physical channel may be filled up with the BCCH, the BSCH is mapped onto block 1 and 
BNCH onto block 2. Whenever a BCCH is mapped on the downlink, a CLCH may also be mapped into the up-link. 

9.5.3 Mapping of SCH for ttM-DQPSK physical cinannels 

On the up-link one SCH/F or two SCH/HU (one on each subslot) may be mapped, except if a CLCH is mapped on 
subslot 1 (formula 3) then only one SCH/HU may be mapped, onto subslot 2. On the down-link one SCH/F or two 
SCH/HD may be mapped on block 1 and block 2 except on the control frame if a BNCH is mapped onto block 2, then 
only one SCH/HD shall be mapped onto block 1 . 

Whenever a normal downlink burst is transmitted on an UP channel and if no BCCH is transmitted then the SCH/HD 
shall be mapped onto block 1 and block 2. The SCH/HD shall contain dummy messages (null SDU as described in 
clause 21). 

The BS shall indicate on the AACH the type of logical channel(s) to be used on the next up-link subslot (SCH/HU or 
CLCH) or slot (SCH/F). This indication shall only be valid within one frame and for one physical channel. 

In the case where several downlink TP channels are allocated to one single communication, the uplink and downlink 
SCH shall be mapped onto frame FN18 of the allocated physical channel showing the lowest timeslot number TN. 

In the case where several uplink TP channels are allocated to one single communication, the uplink and downlink SCH 
shall be mapped onto frame FN18 of the allocated physical channel showing the highest timeslot number TN. 

In the case where several downlink and uplink TP channels have been allocated simultaneously to one single 
communication, the uplink and downlink SCH shall be mapped onto frame FN18 of the allocated physical channel 
showing the lowest timeslot number TN. 

9.5.3a Mapping of SCH for 7r/8-D8PSK pinysical cinannels. 

On the up-link one SCH/F or SCH-P8/F may be mapped. Any combination of SCH/HU and SCH-P8/HU (one on each 
subslot) may be mapped. If a CLCH is mapped on subslot 1 (formula 3) then SCH/HU or SCH-P8/HU may be mapped 
onto subslot 2. 

On the downlink, one SCH/F or one SCH-P8/F or two SCH/HD or two SCH-P8/HD may be mapped on block 1 and 
block 2 except on the control frame if a BNCH is mapped onto block 2, and then only one SCH/HD shall be mapped 
onto block 1 . 

The BS shall indicate on the AACH the type of logical channel(s) to be used on the next up-link subslot or slot. This 
indication shall only be valid within one frame and for one physical channel. 

9.5.4 Mapping of TCH and STCH for pinase modulation 

The TCH shall be mapped onto block 1 and block 2 of the frames 1 to 17 of a TP channel. 

The STCH may be mapped onto any frame allowed for traffic. The STCH steals a part or all of the TCH bits within a 
burst. 

The presence of stolen traffic in one burst shall be indicated by the type of training sequence. 
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In case of stealing, the STCH shall always steal first the first half slot of the burst. 

9.5.5 Mapping of AACH for phase modulation 

The AACH is mapped onto the broadcast block of each downlink slot for both 7t/4-DQPSK and jt/8-D8PSK bursts. 

9.5.6 General mapping of logical channels for QAM 

Table 9.32 defines the mapping in time of logical channels into physical channel types. 

Table 9.32: Mapping of QAM logical channel into QAM physical channels 



Logical 
channel 


Dire- 
ction 


Burst 
type 


SSN 


Physical 
channel 


FN 


TN 


BNCH-Q 


DL 


NDB 


NA 


CP, UP 


1...18 


1...4 


AACH-Q 


DL 


NDB 


NA 


CP,UP 


1...18 


1...4# 


SICH-Q/D 


DL 


NDB 


NA 


CP, UP 


1...18 


1...4# 


SICH-Q/U 


UL 


NUB, CB 


NA 


CP 


1...18 


1...4# 


BLCH-Q 


DL 


LDB 


NA 


CP, UP 


1...18 


1...4 


CLCH-Q 


UL 


LB 


SSN1 
SSN1 


CP 
CP, UP 


18 
1...18 


4-(MA/+1)mod4#(see 

note 2) 

1...4 


SCH-Q/D 


DL 


NDB 


NA 


CP, UP 


1...18 


1...4 


SCH-Q/U 


UL 


NUB 


NA 


CP 


1...18 


1...4 


SCH-Q/HU 


UL 


CB 


SSN1, SSN2 


CP 


1...18 


1...4 


SCH-Q/RA 


UL 


RAB 


SSN1 1 through, 
SSN26 


CP 


1...18 


1...4 


NOTE 1 : # indicates a mandatory mapping. 

NOTE 2: The IVIS shall only use the CLCH-Q in the lowest numbered allocated TN. 



The mapping to the CP channel shall be as summarized in the table 9.33. 

Table 9.33: TDMA frame mapping on QAM CP channel 



Frame 
FN 


DOWNLINK 


UPLINK 






Subslot SSN1 or 

SSWrrthrough 

SSN16 


Subslot SSA/2 or 

SSN21 through 

SSN26 


1 to 18 


SCH-Q/D 
BLCH-Q 
BNCH-Q 


SCH 
SCH-Q/HU 
SCH-Q/RA 
CLCH-Q 


-Q/U 

SCH-Q/HU 
SCH-Q/RA 
SCH-Q/HU 



9.5.7 General mapping of logical channels into unallocated physical 
channels for QAM 

The mapping to UP channel shall be as presented in table 9.34. 

Table 9.34: TDMA frame mapping on QAM unallocated physical channel 



Frame 
FN 


DOWNLINK 


UPLINK 1 






Subslot SSN1 or 

SSWrrthrough 

SSN16 


Subslot SSA/2 or 

SSN21 through 

SSN26 


1 to 18 


SCH-Q/D 
BLCH-Q 
BNCH-Q 


CLCH-Q 
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9.5.8 Mapping of CLCH-Q for QAM 

The CLCH-Q shall be mapped on the control frame of CP channels as presented in table 9.35. 
Table 9.35: Mapping of the BCCH-Q onto the control frame 



Multiframe 


Frame 
FN18 


Timeslot 


TN1 


TN2 


TN3 


TN4 


{MN} mod 4 = 1 


downlink BKN1 










downlink BKN2 










uplink SSN1 




CLCH-Q (note) 






{MN) mod 4 = 2 


downlink BKN1 










downlink BKN2 










uplink SSN1 


CLCH-Q (note) 








{MN) mod 4 = 3 


downlink BKN1 










downlink BKN2 










uplink SSN1 








CLCH-Q (note) 


{MN) mod 4=0 


downlink BKN1 










downlink BKN2 










uplink SSN1 






CLCH-Q (note) 




NOTE: The MS shall only use the lowest numbered assigned timeslot for linearization. 



The mapping of the CLCH-Q on the control frame shall be a function of the time slot and multiframe numbers and shall 
be obtained from the following algorithms or from table 9.35. 

• Up-link: 

CLCH-Q mapped if: 

FN= 18 and (MN + TN) mod 4 = 3 and TA^is the lowest numbered timeslot of the allocated channel (9.19) 

In addition to this mapping the BS may map the CLCH-Q onto the up-link subslot 1 and the BNCH-Q on the downlink 
of a CP channel. The mapping shall be performed on a slot to slot basis. The mapping of the CLCH-Q shall be indicated 
on the AACH-Q. 

The number of BLCH-Q occurrences on one carrier shall not exceed one per 4 multiframe periods. 

At initial power-on of an RF carrier, the BS may linearize its transmitter using the BLCH-Q. In this case the BLCH-Q is 
mapped on a burst similar to the downlink linearization burst, but with an unspecified duration preceding the start burst. 

On a UP channel, the BS may map BNCH-Q on the downlink and may map CLCH-Q onto the uplink subslot 1. 

9.5.9 Mapping of SCH-Q for QAM 

On the up-link one SCH-Q/U or two SCH-Q/HU (one on each subslot) may be mapped, except if a CLCH-Q is mapped 
on subslot 1 (formula 3) then only one SCH/HU may be mapped, onto subslot 2. Alternatively SCH-Q/RA may be 
mapped on the up-link. On the down-link one SCH-Q/D may be mapped. 

The BS shall indicate on the AACH-Q the type of logical channel(s) to be used on the next up-link subslot (SCH-Q/HU, 
SCH-Q/RA or CLCH-Q) or slot (SCH-Q/U). This indication shall only be valid within one frame and for one physical 
channel. 

9.5.1 Mapping of SICH-Q and AACH-Q for QAM 

The SICH-Q/D and AACH-Q shall be mapped onto the header block of each downlink slot except slots containing 
BLCH-Q, and the SICH-Q/U shall be mapped onto the header block of each uplink slot or subslot, except subslots 
containing CLCH-Q or SCH-Q/RA. 

The details of the mapping of the SICH-Q/D and AACH-Q into the bits that define the header block in the downlink 
slot are defined in clause 8. 
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9.6 Monitoring pattern for transmitting IVISs 

A particular monitoring pattern shall be referenced by its Monitoring Pattern Number (MPN). The monitoring patterns 
shall be numbered from 1 to 3. The BS shall assign to 3 patterns to each up-link TCH during the call or transaction 
set-up. The transmitting MS shall monitor at least all frames belonging to the assigned monitoring pattern(s). In some 
cases, the BS may allocate no monitoring pattern, but, as a result, the MS may not be so easily reachable. 

For a given monitoring pattern, the frame sequence may be obtained with the following formula or by using table 9.36. 

(MN + MPN-l)mod 3 = (FN)mod 3 (9.20) 

Table 9.36: Monitoring patterns for transmitting IVISs 



Multiframe 


Monitoring Patterns 


MPN1 


MPN 2 


MPN 3 


{MN}mo6 3 = 1 


FN1, 4, 7, 10, 13, 16 


FN2,5,8, 11, 14, 17 


FN3, 6, 9, 12, 15, 18 


{MN)mo6 3 = 2 


FN2,5,8, 11, 14, 17 


FN3, 6, 9, 12, 15 18 


FN1, 4, 7, 10, 13, 16 


{MN)mo6 3 = 


FN3, 6, 9, 12, 15 18 


FN1, 4, 7, 10, 13, 16 


FN2,5,8, 11, 14, 17 



9.7 BS timesharing transmission 

9.7.1 Carrier sharing for Phase IVIodulation 

In carrier sharing mode one carrier frequency shall be shared among up to four cells, each cell being allocated at least 
one physical channel. The mapping of logical channels into physical channels shall follow the general mapping rules, 
except that on the downlink discontinuous bursts shall be used, (see also clause 23.3.2.1). 

9.7.2 IVICCH sharing for Phase IVIodulation 

In MCCH sharing mode, the MCCH shall be shared among several cells. The TDMA frames of the MCCH shall be 
divided into frames reserved to one BS (reserved frames) and frames shared by all cells (common frames). The BS shall 
transmit during the reserved frames and may transmit during the common frames. The transmission during the common 
frames should be managed by the network (see also clause 23.3.2.2). 

The frames reserved for a BS shall be calculated from the TS_RESERVED_FRAMES parameter that indicates the 
number of reserved frames per two multiframes. This parameter may take one of the following values: 

• 1,2,3,4,6,9,12,18; 

and shall be broadcast on the BSCH. Up to 36 cells may share the same MCCH. The FN of the reserved frames may be 
obtained from the following formula or from table 9.37. 



• the frame FN in the multiframe MN is reserved to the BS if: 

FN +18 [(MN+ l)mod 2] is a multiple of 36/TS_RESERVED_FRAMES 



(9.21) 



For any value of TS_RESERVED_FRAMES, frame 18 of the even multiframes shall be reserved, in order to transmit 
the BCCH. The TDMA frame and multiframe numbering of all cells sharing one MCCH shall be offset in order to 
avoid collision of the transmitted bursts. 

The allocation of the common frames shall be sent on the BNCH. 

The mappings of logical channel into physical channel shall follow for the reserved and common frames the same rules 
as for continuous transmission, except that on the downlink the discontinuous bursts shall be used. 

9.7.3 BS timesharing transmission for QAM 

QAM channels shall not use timesharing. 



ETSI 



169 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



9.8 



Modes of control 



Two modes of control are defined: 

• Normal Control Mode (NCM); and 

• Minimum Control Mode (MCM). 

9.8.1 Normal Control Mode 

The NCM is a mode of operation providing the TETRA services with full performance. In NCM a MCCH shall be 
assigned. 

9.8.2 Minimum Control Mode 

The MCM is a mode of operation providing the TETRA services with reduced performance. In MCM all physical 
channels may be assigned channels. 

Table 9.37: Reserved frames in BS timing 



Multi- 
frame 
MN 


Frame 
FN 


1 


2 


3 


RESERVE! 
4 


3 FRAMES 
6 


9 


12 


18 


odd 


1 


















2 
















^^^^H 


3 














^^^^H 


4 










^^^^H ^^^^H 


5 












1 


6 








^^^^H 


^^^^^^^■^H 


7 












1 


8 










^^^^H ^^^^H 


9 






^^^^H 


^^^^H 


10 














^■^H 


11 














1 


12 






13 
















^ 


14 
















15 














^^^^H 


16 










^■^H 


^H 


17 










1 1 


1 


18 


^^^^H 




even 


1 










1 1 




2 










^■^H 





3 














^^^^1 


^ 


4 
















5 
















6 






7 
















^ 


8 
















9 






^^^^H 


^^^^H 


1 


10 










^■^H 


^H 


11 










1 1 


1 


12 










13 










1 1 




14 










^■^H 





15 














^^^^^ 


^ 


16 
















17 
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1 Radio subsystem link control 
10.1 Introduction 

Clauses 10.2 to 10.4 specify the radio subsystem link control implementation in MSs and BSs for V+D. The following 

aspects of radio subsystem link control are addressed: 

• RF power control; 

• the basis for signal strength measurement; 

• link adaptation (applicable to D8PSK and QAM channels only). 



1 0.2 RF power control 



Adaptive RF power control shall be used by the MS. By minimizing the transmit power levels, interference to 
co-channel and adjacent channel users is reduced and MS power consumption could be reduced. Adaptive RF power 
control shall not be used by the BS. 

10.3 Radio link measurements 

The radio Unk measurements include signal strength, signal quaUty and round-trip MS-BS path delay as presented in 
clauses 10.3.1, 10.3.2 and 10.3.3. 

1 0.3.1 Received signal strengtii 

1 0.3.1 .1 Signal strength measurement 

The received signal strength shall be measured over the range from -115 dBm to -50 dBm with an absolute accuracy of 
+4 dB. The relative accuracy between two measurements on the same carrier or on different carriers shall be +3 dB. 

1 0.3.1 .2 Sample duration for signal strength measurement 

To enable correct measurement of the received signal strength, the minimum Sample Duration (SD) shall be one of the 
following defined values: 

• SDl = 1 ms sample duration (1 ms integration time); 

• SD2 = 4 ms sample duration (4 ms integration time). 

10.3.2 Signal quality 

The quality of the radio downlink shall be estimated from the success rate of decoding the AACH or AACH-Q (see 
clause 23). 



1 0.3.3 Round-trip MS-BS path delay 



The round-trip MS-BS path delay may be used by the BS as a criterion to relinquish a radio uplink. The path delay of 
the MS is a representation of the distance of the MS to the serving BS. This distance may be used to prevent MS grossly 
exceeding the planned cell boundaries. This information may be sent by the BS to the MS when appropriate. The 
allowable distance may be restricted on a cell to cell basis by the network operator, as required. 
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10.4 Link adaptation 



Link adaptation may be used by the BS and MS to improve usage of the channel. This is achieved by the BS and/or MS 
transmitters changing the modulation type and/or coding rate, refer to clause 23.2.3. Link adaptation methods may 
include measurements of the radio link quality and/or the use of BS-MS link adaptation signalling, refer to 
clauses 23.1.4 and 23.4.9. 
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1 1 Call Control (CC) service description 

11.1 Introduction 

This clause describes the services offered by the CC sub-entity in the Circuit Mode Control Entity (CMCE). The CC 
Service Access Point (SAP) is used in conformance testing as a normative boundary in TETRA MSs and TETRA LSs. 

1 1 .2 Services offered 

The CC services shall be provided with a CC sub-entity at the service access point TNCC-SAP. In order to cater for 
concurrent services there may exist multiple instances of the TNCC-SAP running at the same time. 

At the TNCC-SAP one instance of the call control shall consist a set of the following calling user application and called 
user application services: 

basic call set-up (with attributes); 

call maintenance; 

Dual Tone Multiple Frequency (DTMF) encoding and sending; 

PTT requests/grants/information; 

call clearance; 

change of tele/bearer service within a call. 
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1 1 .3 CC service 

1 1 .3.1 CC primitives exclnanged tinrougin tine TNCC-SAP 

The flow of CC primitives shall be as illustrated in figure 11.1. 



/\ 



SIGNAL 

TNCC-ALERT indication 
TNCC-COMPLETE confirm 
TNCC-COMPLETE indication 
TNCC-COMPLETE request 
TNCC-DTMF indication 
TNCC-DTMF request 
TNCC-MODIFY indication 
TNCC-MODIFY request 
TNCC-NOTIFY indication 
TNCC-PROCEED indication 
TNCC-RELEASE indication 
TNCC-RELEASE confirm 
TNCC-RELEASE request 
TNCC-SETUP confirm 
TNCC-SETUP indication 
TNCC-SETUP request 
TNCC-SETUP response 
TNCC-TX indication 
TNCC-TX request 
TNCC-TX confirm 
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TNCC-SAP 



< 



TNCC-COMPLETE request 
TNCC-DTMF request 
TNCC-MODIFY request 
TNCC-RELEASE request 
TNCC-SETUP request 
TNCC-SETUP response 
TNCC-TX request 



> 



\/ 



CC Service MS/LS 



Figure 11.1 : CC services provided at TNCC-SAP IVIS-side 

1 1 .3.2 Service primitives at tine TNCC-SAP 

Each TNCC-SAP shall be characterized by a SAP and the set of service primitives available for each SAP shall be as 
specified in this clause. 

TNCC-ALERT indication: the primitive shall be used in the call set-up phase towards the calling user application 
when on/off hook signalling is employed. 

TNCC-COMPLETE request/indication/confirm: the primitives shall be used as a termination of the call set-up phase 
at the called user application. 

TNCC-DTMF request/indication: the primitives may be used during a circuit mode call to exchange DTMF 
information between user applications. 

TNCC-MODIFY request/indication: the primitives may be used during call active phase as an indication that an 
existing tele or bearer service has been modified. 

TNCC-NOTIFY indication: the primitives may be used during call set-up and call active phases to notify the user 
application about the status of the call. 
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TNCC-PROCEED indication: the primitive may be used during call set-up phase to indicate progress of the call 
set-up. 

TNCC-RELEASE request/indication/confirm: the primitives shall be used to initiate the call release phase. Further it 
shall be used to indicate the termination of the call release phase. The primitives may also be used during the call set-up 
phase to request or indicate rejection of a call. 

TNCC-SETUP request/indication/response/confirm: the primitives shall be used to initiate the call set-up phase and 
shall also be used to indicate the termination of the call set-up phase. 

TNCC-TX request/indication/confirm: the primitives shall be used during call active phase to request and indicate 
change in the transmission permission. 

1 1 .3.3 Primitive description 

The information contained in the primitive description tables which follow corresponds to the following key: 
M: Mandatory; 
C: Conditional; 
O: Optional; 
-: Not used. 

1 1 .3.3.1 TNCC-ALERT primitive 

TNCC-ALERT indication: the primitive shall be used to indicate to the calling user application, that the call has been 
received, and alerting at the called user application has been initiated. The called user application is using on/off hook 
signalling and the primitive indicates that the called user application is alerting. 

The parameters are defined in table 11.1. 

Table 11.1: Parameters for the primitive TNCC-ALERT 



Parameter 


Indication 


Basic service information (offered): 




Circuit mode service 





Communication type 





Data call capacity 


C (see note) 


Data service 


C (see note) 


Encryption flag 





Speech service 


C (see note) 


Call queued 





Call time-out, set-up phase 


M 


Notification indicator 





Simplex/duplex 


M 


NOTE: Depending on the value of circuit mode service. 
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1 1 .3.3.2 TNCC-COMPLETE primitive 

TNCC-COMPLETE request: the primitive shall be used by the called user application to complete individual call 

set-up. 

TNCC-COMPLETE indication: the primitive shall be used as an indication to the called user application that the call 
set-up has been completed. The called user application shall also be informed whether the SwMI has granted 
transmission permission to the calling user application or whether the right to transmit has been handed over to the 
another user application. 

TNCC-COMPLETE confirm: the primitive shall be used to confirm to the called user application that the call set-up 
has been completed. 

The parameters are defined in table 1 1.2. 

Table 11.2: Parameters for the primitive TNCC-COIUIPLETE 



Parameter 


Request 


Indication 


Confirm 


Access priority 





- 


- 


Basic service information (offered): 








Circuit mode service 





- 


- 


Communication type 





- 


- 


Data call capacity 


C (see note) 


- 


- 


Data service 


C (see note) 


- 


- 


Encryption flag 





- 


- 


Speech service 


C (see note) 






Call time-out 


- 


M 


M 


Hook method 


M 


- 


- 


Notification indicator 


- 








Simplex/duplex 


M 


- 


- 


Transmission grant 


- 


M 


M 


Transmission request permission 


- 


M 


M 


Transmission status 


- 


M 


M 


Traffic stealing 





- 


- 


NOTE: Depending on the value of circuit mode service. 



1 1 .3.3.3 TNCC-DTMF primitive 

TNCC-DTMF request: the primitive shall be used as a request from the user application to send a number of DTMF 
digits to another user application. 

TNCC-DTMF indication: the primitive shall be used as an indication to the user application that a number of DTMF 
digits has arrived from another user application. 

The parameters are defined in table 11. 3. 

Table 11.3: Parameters for the primitive TNCC-DTIUIF 



Parameter 


Request 


Indication 


Access priority 





- 


DTIVIFtone delimiter 


M 


(see note 4) 


DTIVIF result 


- 


C (see note 3) 


Number of DTIVIF digits 


C (see note 1 ) 


C (see note 2) 


DTMF digits 


C (see note 1 ) 


C (see note 2) 


Traffic stealing 





- 


NOTE 1 
NOTE 2 
NOTES 
NOTE 4 


Present when the value of DTMF tone delimiter is "DTMF tone start". 

Present when DTMF tone delimiter is present and set to "DTMF tone start". 

Present when DTMF tone delimiter is not present. 

The time difference between "DTMF tone start" and "DTMF tone end" may not correspond 

to the tone duration at the originator. 
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11.3.3.4 TNCC-MODIFY primitive 

TNCC-MODIFY request: the primitive shall be used as a request from the user application to the SwMI to change the 
call attributes and/or the simplex/duplex selection. 

NOTE: If a change in call attribute is requested, it cannot change from point-to-multipoint to point-to-point. 

TNCC-MODIFY indication: the primitive shall be used as an indication to a user application that the call attribute has 
changed from one tele/bearer service to another tele/bearer service. The primitive shall also be used for indicating a 
change in the call timer or a change in the simplex/duplex operation. 

The parameters are defined in table 1 1 .4. 

Table 11.4: Parameters for the primitive TNCC-IUIODIFY 



Parameter 


Request 


Indication 


Access priority 





- 


Basic service information (new): 






Circuit mode service 








Communication type 








Data call capacity 


C (see note) 


C (see note) 


Data service 


C (see note) 


C (see note) 


Encryption flag 








Speech service 


C (see note) 


C (see note) 


Call time-out 


- 





Notification indicator 


- 





Simplex/duplex 








Traffic stealing 





- 


NOTE: Depending on the value of circuit mode service. 



1 1 .3.3.5 TNCC-NOTIFY primitive 

TNCC-NOTIFY indication: the primitive shall provide information from the SwMI to the user application about a 
circuit mode call. 

The parameters are defined in table 11. 5. 

NOTE: EN 300 392-9 [9] defines in clause 5.2 "NOTIFICATION indication primitive" that the NOTIFICATION 
indication is also providing information to the user application about the circuit mode call. 

Table 11.5: Parameters for the primitive TNCC-NOTIFY 



Parameter 


Indication 


Call status 





Call time-out in set-up phase 





Call time-out 





Call ownership 





Notification indicator 





Poll response percentage 


(see note) 


Poll response number 


(see note) 


Poll response addresses 


(see note) 


Poll request 





NOTE: Only one of these values is applicable in a service primitive. 
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1 1 .3.3.6 TNCC-PROCEED primitive 

TNCC-PROCEED indication: the primitive shall be used as an indication to the user application that call 
establishment has been initiated in the SwMI. The indication may also contain information about changes in call 
attributes, changes in the hook method or the simplex/duplex operation. 

The parameters are defined in table 11. 6. 

Table 11.6: Parameters for the primitive TNCC-PROCEED 



Parameter 


Indication 


Basic service information (offered): 




Circuit mode service 





Communication type 





Data call capacity 


C (see note) 


Data service 


C (see note) 


Encryption flag 





Speech service 


C (see note) 


Call status 





Hook method 





Notification indicator 





Simplex/duplex 





NOTE: Depending on the value of circuit mode service. 



1 1 .3.3.7 TNCC-RELEASE primitive 

TNCC-RELEASE request: the primitive shall be used by the user application to either leave a continuing call or 
request disconnection of the call. If he wants to disconnect the call the SwMI is requested to release the connection. The 
SwMI is also requested to release the call identifier and all connections associated with it. 

TNCC-RELEASE indication: the primitive shall be used as an indication to the user application, that the SwMI has 
released the call identifier and the corresponding connection. This primitive may also indicate a loss of resources at 
a lower layer. 

TNCC-RELEASE confirm: the primitive shall be used to indicate to the initiator of the call release, that the SwMI has 
released the call identifier and the connection. 

The parameters are defined in table 11. 7. 

Table 11.7: Parameters for the primitive TNCC-RELEASE 



Parameter 


Request 


Indication 


Confirm 


Access priority 





- 


- 


Disconnect cause 


M 


M 


M 


Disconnect status 


- 


- 


M 


Disconnect type 


M 


- 


- 


Notification indicator 


- 








Traffic stealing 





- 


- 



1 1 .3.3.8 TNCC-SETUP primitive 

TNCC-SETUP request: the primitive shall be used to initiate the call establishment of a circuit switched call by a 
calling user application. 

TNCC-SETUP indication: the primitive shall be used as an indication to a called user application that a call 
establishment has been initiated and a circuit switched call is in progress or has been established. 

TNCC-SETUP response: the primitive shall be used by the called user application to indicate that the call has been 
accepted and call set-up can now proceed towards the call active phase. The user application may change the attributes 
of the call and the simplex/duplex operation may be changed. 
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TNCC-SETUP confirm: the primitive shall be used as a confirmation to the calling user application that the call set-up 
phase has now been terminated by the SwMI and an end-to-end connection has been set-up. The call shall now be 
considered as being in its active phase. 

The parameters are defined in table 11. 8. 

Table 11.8: Parameters for the primitive TNCC-SETUP 



Parameter 


Request 


Indication 


Response 


Confirm 


Access priority 





- 





- 


Area selection 


(see note 6) 


- 


- 


- 


Basic service information: 










Circuit mode service 


M 


M 





M 


Communication type 


M 


M 





M 


Data call capacity 


C (see note 1 ) 


C (see note 1 ) 


C (see note 1 ) 


C (see note 1 ) 


Data service 


C (see note 1 ) 


C (see note 1 ) 


C (see note 1 ) 


C (see note 1 ) 


Encryption flag 


M 


M 





M 


Speech service 


C (see note 1 ) 


C (see note 1 ) 


C (see note 1 ) 


C (see note 1 ) 


Call priority 


M 


M 


- 





Call ownership 


- 


- 


- 


M 


Call amalgamation 


- 


- 


- 


M 


Call time-out 


- 


M 


- 


M 


Called party type identifier 


M 


- 


- 


- 


Called party SNA 


C (see note 2) 


- 


- 


- 


Called party SSI 


C (see notes 2 
and 3) 


M 


- 


- 


Called party extension 


C (see note 2) 


(see note 4) 


- 


- 


External subscriber number (called) 





- 


- 


- 


Calling party: 










Calling party SSI 


- 





- 


- 


Calling party extension 


- 


(see note 4) 


- 


- 


External subscriber number (calling) 


- 





- 


- 


CLIR control 


(see note 7) 


(see note 7) 


(see note 7) 


- 


Hook method selection 


M 


M 


M 


M 


Notification indicator 


- 





- 





Request to transmit/send data 


M 


- 


- 


- 


Simplex/duplex selection 


M 


M 


M 


M 


Traffic stealing 





- 





- 


Transmission grant 


- 


M (see note 5) 


- 


M (see note 5) 


Transmission request permission 


- 


M 


- 


M 


NOTE 1 : Depending on the value of circuit mode service type. 

NOTE 2: Depending on the value of called party type identifier. 

NOTE 3: The application should ensure that individual calls (basic service) use called party ISSI, and group calls use 

GSSI. 
NOTE 4: If not present, the user application shall assume that the address extension is the MNI of the current 

network. 
NOTE 5: Transmission grant is applicable also in duplex calls. 
NOTE 6: Usage of this parameter is defined in EN 300 392-1 2-8 [1 4]. 
NOTE 7: Usage of this parameter is defined in EN 300 392-12-1 [11]. 
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1 1 .3.3.9 TNCC-TX primitive 

TNCC-TX request: the primitive shall be used as a request from the user application that it wants to transmit or that it 
has ceased its transmission. In the request for transmission the requested priority and the encryption mode shall be 
indicated. The user application should use a TNCC-TX request for a request to transmit only when a previous 
TNCC-TX indication has indicated that a request for transmission is allowed. 

TNCC-TX indication: the primitive shall be used as an indication to the user application concerning the transmit status 
of the call. The primitive shall also be used to inform the user application about whether another user has been granted 
transmission or ceased its transmission. The encryption state of the actual transmission is indicated in the encryption 
control parameter. 

TNCC-TX confirm: the primitive shall be used as a confirmation to the user application that the request to transmit has 
been granted. The encryption state of the actual transmission is indicated in the encryption control parameter. 

The parameters are defined in table 11. 9. 

Table 11.9: Parameters for the primitive TNCC-TX 



Parameter 


Request 


Indication 


Confirm 


Access priority 





- 


- 


Encryption flag 


M 


M 


M 


Notification indicator 


- 





- 


Transmitting party SSI 


- 





- 


Transmitting party extension 


- 


(see note) 


- 


External subscriber number 


- 





- 


Traffic stealing 





- 


- 


Transmission condition 


M 


- 


- 


Transmit request permission 


- 


M 


M 


Transmission status 


- 


M 


M 


Tx demand priority 


M 


- 


- 


NOTE: If not present, the user application shall assume that the address extension is the MNI of the 
current network. 



1 1 .3.4 Parameter description 



Parameters shall be part of the primitives described in clause 1 1 .3.3 and if applied the parameters shall contain the 
values specified in this clause. These values are selected to correspond to element values used in the air interface 
protocol. 

• Access priority = 

low priority; 

high priority; 

emergency priority. 

The default value of the access priority parameter shall be "low priority", which will be applied when no access priority 
parameter is explicitly defined. 

• Area selection = 

area not defined; 

area 1; 

etc.; 

area 14; 

all areas in this system. 
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The default value of the area selection parameter shall be "area not defined", which will be applied when area selection 
is not used. 

• Basic service information (a set of parameters) = 

circuit mode service; 

communication type; 

data service; 

data call capacity (data service only); 

encryption flag; 

speech service. 

• Call amalgamation = 

call not amalgamated; 
call amalgamated. 

• Call ownership = 

a call owner; 
not a call owner. 

• Call priority = 

priority not defined; 

lowest priority; 

etc.; 

highest non-pre-emptive priority; 

lowest pre-emptive priority; 

etc.; 

second highest pre-emptive priority; 

emergency pre-emptive priority. 

• Call queued = 

call is not queued; 
call is queued. 

• Call status = 

call status unknown; 

call is progressing; 

call is queued; 

requested subscriber is paged; 

call continue; 

hang timer has expired. 
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• Call time-out = 

call time-out infinite; 
call time-out value- 1; 
call time-out value-2; 
etc.; 

call time-out value-15. 
Refer to clause 14.2.15 for the time-out values. 

• Call time-out in set-up phase = 

call time-out pre-defined; 
call time-out value- 1; 
call time-out value-2; 
etc.; 

call time-out value-7. 
Refer to clause 14.2.16 for the time-out values. 

• Called party extension = 

country code and network code part of TSI. 

• Called party SNA = 

Short Number Address (SNA). 

• Called party SSI = 

Short Subscriber Identity (SSI). 

• Called party type identifier = 

SNA; 

SSI; 

TETRA subscriber identity (TSI). 

• Calling party extension = 

Mobile Country Code (MCC) + Mobile Network Code (MNC). 

• Calling party SSI = 

Individual Short Subscriber Identity (ISSI). 

• Circuit mode service = 

data service; 
speech service. 
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• CLIR control = 

not implemented or use default mode; 
presentation not restricted; 
presentation restricted. 

• Communication type = 

point-to-point; 
point-to-multipoint; 
point-to-multipoint acknowledged; 
broadcast. 

• Data service (service per one time slot) = 

unprotected: 7,2 kbit/s, no interleaving; 

low protection: 4,8 kbit/s, short interleaving depth = 1 ; 

low protection: 4,8 kbit/s, medium interleaving depth = 4; 

low protection: 4,8 kbit/s, long interleaving depth = 8; 

high protection: 2,4 kbit/s, short interleaving depth = 1 ; 

high protection: 2,4 kbit/s, medium interleaving depth = 4; 

high protection: 2,4 kbit/s, long interleaving depth = 8. 

NOTE 1 : The increase in interleaving depth gives a better error protection, but also generates a longer transmission 
delay. 

• Data call capacity = 

one time slot; 
two time slots; 
three time slots; 
four time slots. 

• Disconnect cause = 

cause not defined or unknown; 

user requested disconnect; 

called party busy; 

called party not reachable; 

called party does not support encryption; 

congestion in infrastructure; 

not allowed traffic case; 

incompatible traffic case; 

requested service not available; 

pre-emptive use of resource; 
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invalid call identifier; 

call rejected by the called party; 

no idle CC entity; 

expiry of timer; 

SwMI requested disconnection; 

acknowledged service not completed; 

loss of resources; 

usage marker failure; 

called party requires encryption; 

concurrent set-up not supported; 

called party is under the same DM-GATE of the calling party. 
Disconnect status = 

disconnection successful; 

disconnection unsuccessful, the user is released from the call; 

disconnection unsuccessful, not the call owner, the user is released from the call; 

the user is released from the call. 
Disconnect type = 

disconnect call; 

leave call without disconnection; 

leave call temporarily. 
DTMF digits = 

Each digit shall be one of the following: 

digit 0; 

etc.; 

digit 9; 

digit *; 

digit #; 

digit A; 

digit B; 

digit C; 

digit D. 
DTMF result = 

DTMF not supported; 

DTMF not subscribed. 
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• DTMF tone delimiter = 

DTMF; 

tone end. 

NOTE 2: The length of the received DTMF tone may be modified by the lower layer protocol depending on the 
signalling capacity availability. 

• Encryption flag = 

clear end-to-end transmission; 
encrypted end-to-end transmission. 

• External subscriber number digits = 

Up to 24 digits. Each digit shall be one of the following: 

digit 0; 

etc.; 

digit 9; 

digit *; 

digit #; 

digit +. 

• Hook method selection = 

no hook signalling (direct through-connect); 

hook on/hook off signalling (individual call); and call acceptance signalling (group call). 

• Notification indicator = 

refer to EN 300 392-9 [9], clause 7.2.2. 

• Number of DTMF digits = 

1 to 254. 

• Poll request = 

no poll answer requested; 
poll answer requested. 

• Poll response addresses = 

TSI addresses 1-N. 

• Poll result identifier = 

poll result not known; 

the percentage of responding group members; 

the number of responding group members; 

the addresses of the responding group members. 
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• Poll response number = 

no poll response; 

1 poll response; 

etc.; 

63 or more poll responses. 

• Poll response percentage = 

0%; 
1 %; 
etc.; 
100 %. 

• Request to transmit/send data = 

request to transmit/send data; 

request that other MS/LS may transmit/send data. 

• Simplex/duplex selection = 

simplex operation; 
duplex operation. 

• Speech service = 

TETRA encoded one timeslot speech; 
proprietary encoded one timeslot speech. 

• Traffic stealing = 

do not steal traffic; 

steal traffic. 

The default value of the traffic stealing parameter shall be "do not steal traffic", which will be applied when no traffic 
stealing parameter is explicitly defined, not used or otherwise defined in the protocol. 

• Transmission condition = 

request to transmit; 
transmission ceased. 

• Transmission grant = 

transmission granted; 
transmission not granted; 
transmission request queued; 
transmission granted to another user. 

• Transmission request permission = 

allowed to request for transmission; 
not allowed to request for transmission. 
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• Transmission status = 

transmission ceased; 
transmission granted; 
transmission not granted; 
transmission request queued; 
transmission granted to another user; 
transmission interrupt; 
transmission wait; 
transmission request failed. 

• Transmitting party extension = 

Mobile Country Code (MCC) + Mobile Network Code (MNC). 

• Transmitting party SSI = 

Individual Short Subscriber Identity (ISSI); or 
Group Short Subscriber Identity (GSSI). 

• Tx demand priority = 

low priority; 

high priority; 

pre-emptive priority; 

emergency pre-emptive priority. 

The default value of the TX demand priority parameter shall be "low priority", which will be applied when no TX 
demand priority parameter is explicitly defined. 
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1 1 .4 States for CC SAP 

The state transitions visible at the TNCC-S AP shall be as shown in figure 1 1 .2. 



TNCC-RELEASE request 






TNCC-RELEASE request 




TNCC PROCEED indication 
TNCC-NOTIFY indication 
TNCC-MODIFY indication 
TNCC-ALERT indication^ 

MO_CALL 

SETUP 



TNCC-RELEASE indication 



TNCC-RELEASE indication 



/\ 



/ TNCC-SETUP response 
TNCC-RELEASE request 
TNCC-NOTIFY indication 
TNCC-COMPLETE request 
TNCC-MODIFY request 
TNCC-MODIFY indication 



TNCC-SETUP confirnKA 



TNCC-DTMF request/indication 
TNCC-MODIFY request/indication 
TNCC-NOTIFY request/indication 
TNCC-TX request/indication/confirm 



I CALL Y 
1 ACTIVE j 



TNCC-COMPLETE indication 
TNCC-COMPLETE confirm 
TNCC-SETUP indication 
TNCC-SETUP response 



Figure 11 .2: State transition diagram for one instance at the CC SAP 
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12 Supplementary Service (SS) service description 
12.1 Introduction 

This clause describes general services offered by the CMCE at the SS SAP of the TETRA V+D layer 3 service 
boundary. This SAP with the CC SAP is used in supplementary service conformance testing as a normative boundary in 
TETRA MSs and in TETRA LSs. 



12.2 Services offered 

The SS services are provided at the TNSS-SAP and TNCC-SAP. Refer to clause 11.3 on those supplementary services 
which utilize also TNCC-SAP. For call related actions the TNSS-SAP and TNCC-SAP are linked together by the call 
instance and, therefore, there is no "call identifier" parameter in the primitives. 

The SS may consist of the following services: 

invocation of an SS; 

activation/deactivation of an SS; 

definition of an SS; 

cancellation of an SS; 

interrogation of an SS; 

registration of a user to a supplementary service; 

reception of supplementary service messages. 



12.3 SS service 

1 2.3.1 Primitives exclnanged tinrougin TNSS-SAP 

The SS primitives are defined in EN 300 392-9 [9] and in each supplementary service stage 3 description 
EN/ETS 300 392-12 [10], when available. 

The supplementary service primitives shall contain in addition to supplementary services specific parameters also the 
access priority parameter as defined in table 12.1. 

Table 12.1 : Parameters for the supplementary service primitives 



Parameter 


Request 


Indication 


Response 


Confirm 


Access priority 





- 





- 


Supplementary service dependent parameters 
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12.3.2 Parameter description 



Parameters shall be part of the primitives described in clause 12.3.1 and if applied the parameters shall contain the 
values specified in this clause. These values are selected to correspond to element values used in the air interface 
protocol. 

• Access priority = 

low priority; 

high priority; 

emergency priority. 

The default value of the access priority parameter shall be "low priority", which will be applied when no access priority 
parameter is explicitly defined. 



13 Short Data Service (SDS) service description 

13.1 Introduction 

This clause describes the services offered by the short data service sub-entity in the CMCE at the SDS SAP of the 
TETRA V+D layer 3 service boundary. The SDS SAP is used in conformance testing as a normative boundary in 
TETRA MSs and in TETRA LSs. 

13.2 Services offered 

The SDS shall be provided by a single SDS functional entity at the TNSDS-SAP. 

The short data functional entity shall consist of the following mobile originated and mobile terminated services: 

a) user defined short message reception and transmission; 

individual message; 
group message. 

b) pre-defined short message reception and transmission; 

individual message; 
group message. 

13.3 SDS 

1 3.3.1 SDS primitives exclnanged tinrougin tine TNSDS-SAP 

TNSDS-CANCEL request: the primitive may be used by the user application to cancel sending of a message before it 
is sent at least once over the air interface. 

TNSDS-STATUS request/indication: the primitives shall be used to send or receive a pre-coded message defined by 
either the present document or by the network operator. 

TNSDS-REPORT indication: the primitive shall be used to indicate whether a TNSDS-UNITDATA request or a 
TNSDS-STATUS request has been either transmitted successfully or the transmission failure reason. 

TNSDS-UNITDATA request/indication: the primitives shall be used to send or receive a user defined message. 

The flow of short data service primitives shall be as illustrated in figure 13.1. 
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SIGNAL 

TNSDS-CANCEL request 
TNSDS-STATUS indication 
TNSDS-STATUS request 
TNSDS-REPORT indication 
TNSDS-UNITDATA indication 
TNSDS-UNITDATA request 



"K 



TNSDS-STATUS indication 
TNSDS-REPORT indication 
TNSDS-UNITDATA indication 



TNSDS-SAP 



TNSDS-CANCEL request 
TNSDS-STATUS request 
TNSDS-UNITDATA request 




Figure 13.1 : SDS provided at TNSDS-SAP (IVIS-side) 

1 3.3.2 Service primitives at tine TNSDS-SAP 

The information contained in the primitive description tables which follow corresponds to the following key: 
M: Mandatory; 
C: Conditional; 
O: Optional; 

-: Not used. 

The SDS-TL protocol modifies the TNSDS primitives so that a certain range of Status number values of the 
TNSDS-STATUS primitives are used by the SDS-TL protocol and the User defined data-4 parameter is only available 
via the SDS-TL-SAP, refer to clause 29.1.1. 

13.3.2.1 TNSDS-STATUS primitive 

TNSDS-STATUS request: the primitive shall be used by the user application to send a pre-defined message to another 
user or users given in the address parameter. 

NOTE: The status message is selected from a set of pre-coded messages and only the status number is given as a 
parameter. 

TNSDS-STATUS indication: the primitive shall indicate to the user application that a pre-coded status message from 
another user application has been received. 
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The parameters are defined in table 13.1. 



Table 13.1 : Parameters for the TNSDS-STATUS primitive 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 


(see note 3) 


- 


Called party type identifier 


M 


- 


Called party SNA 


C (see note 1 ) 


- 


Called party SSI 


C (see note 1 ) 


M 


Called party extension 


C (see note 1 ) 


(see note 2) 


Called party address type 


- 





External subscriber number (called) 







Calling party SSI 


- 


M 


Calling party extension 


- 


(see note 2) 


External subscriber number (calling) 







Status number 


M 


M 


Handle 


M 


- 


NOTE 1 : Depending on the value of called party type identifier. 

NOTE 2: If not present, the user application shall assume that the address extension is the IVINI of 

the current network. 
NOTE 3: Usage of this parameter is defined in EN 300 392-1 2-8 [1 4]. 



1 3.3.2.2 TNSDS-REPORT primitive 

TNSDS-REPORT indication: the primitive shall be used as an indication to the user application that the PDU 
belonging to a request, i.e. the TNSDS-UNITDATA request or the TNSDS-STATUS request, has been either 
transmitted successfully or lost. 

The parameters are defined in table 13.2. 

Table 13.2: Parameters for the TNSDS-REPORT primitive 



Parameter 


Indication 


Transfer result 


M 


Handle 


M 



13.3.2.3 TNSDS-UNITDATA primitive 

TNSDS-UNITDATA request: the primitive shall be used by the user application to send a user defined message to 
another user application or applications given in the address parameter. 

TNSDS-UNITDATA indication: the primitive shall be used as an indication to the user that a user application defined 
message from another user application has been received. The message may either be a user defined individual message 
or a user defined group message. 
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The parameters are defined in table 13.3. 



Table 13.3: Parameters for the TNSDS-UNITDATA primitive 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 


(see note 5) 


- 


Called party type identifier 


M 


- 


Called party SNA 


C (see note 1 ) 


- 


Called party SSI 


C (see note 1 ) 


M 


Called party extension 


C (see note 1 ) 


(see note 2) 


Called party address type 


- 





External subscriber number (called) 





- 


Calling party: 






Calling party SSI 


- 


M 


Calling party extension 


- 


(see note 2) 


External subscriber number (calling) 


- 





Short data type identifier 


M 


M 


User defined data-1 


C (see note 3) 


C (see note 3) 


User defined data-2 


C (see note 3) 


C (see note 3) 


User defined data-3 


C (see note 3) 


C (see note 3) 


User defined data-4 


C (see notes 3 and 4) 


C (see notes 3 and 4) 


NOTE 1 : Depending on the value of called party type identifier. 

NOTE 2: If not present, the user application shall assume that the address extension is the MNI of the current network. 

NOTE 3: Depending on the value of short data type identifier. 

NOTE 4: This parameter is modified by the SDS-TL protocol and it contains always a protocol identifier, and is available 

via the SDS-TL-SAP, refer to clause 29.1 .1 . 
NOTE 5: Usage of this parameter is defined in EN 300 392-1 2-8 [1 4]. 



13.3.2.4 TNSDS-CANCEL primitive 

TNSDS-CANCEL request: the primitive may be used by the user application to cancel sending of a message before it 
is sent at least once over the air interface. 

13.3.3 Parameter description 

Parameters shall be part of the primitives at the TNSDS SAP. When applied the parameters shall contain the values 
specified in this clause. 

• Access priority = 

low priority; 

high priority; 

emergency priority. 

The default value of the access priority parameter shall be low priority, which will be applied when no access priority 
parameter is used. 
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• Area Selection = 

area not defined; 

area 1; 

etc.; 

area 14; 

all areas in this system. 

The default value of the area selection parameter shall be "area not defined", which will be applied when area selection 
is not used. 

• Called party address type = 

broadcast; 
individual; 
group. 

• Called party extension = 

MCC + MNC. 

• Called party short number address = 

SNA. 

• Called party SSI = 

ISSI; 
GSSI. 

• Called party type identifier = 

SNA; 

SSI; 

TSI. 

• Calling party extension = 

MCC + MNC. 

• Calling party SSI = 

ISSI. 

• External Subscriber Number = 

Up to 24 digits. Each digit shall be one of the following: 
digit 0; 
etc.; 
digit 9; 
digit * 
digit #: 
digit +. 
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• Handle = 

a local SDU identifier. 

• Status number = 

emergency call; 

1 to 31 743 reserved; 

32 768 to 65 535 available for TETRA network specific definition. 

NOTE 1 : Further status number definitions may be added in the maintenance of the present document as an annex. 

NOTE 2: Pre-defined status values from 31 744 to 32 767 are used by SDS-TL protocol and will not be available as 
pre-defined status values. 

• Short data type identifier = 

user defined data- 1 
user defined data-2 
user defined data-3 
user defined data-4. 

• Traffic stealing = 

do not steal traffic; 

steal traffic. 

The default value of the traffic stealing parameter shall be do not steal traffic, which will be applied when no traffic 
stealing parameter is used. 

• Transfer result = 

success; 
failure. 

• User defined data 1 = 

16 bit user defined data. 

• User defined data 2 = 

32 bit user defined data. 

• User defined data 3 = 

64 bit user defined data. 

• User defined data-4 = 

protocol identifier; and 

user defined data bits, maximum length 2 039 bits. 
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13.3.4 State description 

13.3.4.1 NULL state 

No short data message shall be in progress. 

13.3.4.2 SHORT DATA INITIATED state 

Short data message sending in progress state. Waiting for the completion of a message transfer. 

1 3.3.5 Service state diagram for tine TNSDS-SAP 

Supplementary services state diagram is presented in figure 13.2. 

TNSDS-UNITDATA indication 

TNSDS-STATUS indication ^ ^ 

y^^ ^\TNSDS-REPORT indication^ 

( NULL \^ (SHORT DATA] 

INITIATED 




\^___^T 




TNSDS-UNITDATA request^ 
TNSDS-STATUS request 

Figure 13.2: Service state diagram for the mobile terminated short data message 
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14 CMCE protocol 

14.1 Introduction 

This clause defines the layer 3.2 CMCE air interface protocol for the MS. There shall be a peer-to-peer relationship 
between the layers on the terminal side and the SwMI side. The protocol for the SwMI side is, however, outside the 
scope of the present document. The CMCE protocol is the network layer protocol that shall be used to provide services 
to an end user application in the area of CC services, of SDS and of supplementary services. 

This clause specifies: 

• the functional requirements for implementations claiming conformance to the present document; 

• procedures for specific transmission of: 

control information for circuit mode services; 

call unrelated short data messages; 

control information for call related/call unrelated supplementary service messages. 

• the encoding of the Protocol Data Units (PDUs) used for the transmission of data and control information; 

• procedures for the correct interpretation of protocol control information. 

14.2 Overview of CMCE 

Figure 14.1 shows the position of the CMCE protocols in both the MS and in the BS protocol stack. The present 
document does not define a BS protocol architecture or user application SAPs for the CMCE within the SwMI. 

User applications 



TNCC-SAP 



TNSS-SAP 



TNSDS-SAP 



CIVICE IVIS 



LCIVIC-SAP 



CIVICE BS 



LCMC-SAP 



MLE 



CMCE-MS Circuit Mode Control Entity, Mobile Station 

CMCE-BS Circuit Mode Control Entity, Base Station 

LCMC-SAP Mobile Link Entity - Circuit Mode Control Service Access Point 

MLE Mobile Link Entity 

TNCC-SAP TETRA Network - Call Control Service Access Point 

TNSDS-SAP TETRA Network - Short Data Service Service Access Point 

TNSS-SAP TETRA Network - Supplementary Service Service Access Point 

Figure 14.1 : System view 
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1 4.2.1 Communication routes of tine CMCE model 

The CMCE model defines routes used for information exchange between the sub-entities as shown in figure 14.2. 

The external routes are routes between a sub-entity of the CMCE and an entity in another layer. Each external route 
shall be mapped onto a SAP. 

There are four external routes. 

• The ra route shall correspond to the TNCC-SAP. The primitives exchanged on that route are described in 
clause 11. 

• The rb route shall correspond to the TNSS-SAP. The primitives exchanged on that route are described in 
clause 12. 

• The re route shall correspond to the TNSDS-SAP. The primitives exchanged on that route are described in 

clause 13. 

• The ri route shall correspond to the LCMC-SAP. The primitives exchanged on that route are described in 

clause 17. 

The internal routes are routes between sub-entities of the CMCE. 
There are five internal routes: 

• the rd route shall be a route between the CC sub-entity and the PC sub-entity; 

• the re route shall be a route between the SS sub-entity and the PC sub-entity; 

• the rg route shall be a route between the SS sub-entity and the CC sub-entity; 

• the rf route shall be a route between the SDS sub-entity and the PC sub-entity; 

• the rh route shall be a route between the SS sub-entity and the SDS sub-entity. 

1 4.2.2 Protocol structure and protocol stack 

The CMCE is the layer 3 sub-layer for circuit mode CC, SS and SDS as described in clauses 1 1, 12 and 13 respectively. 
CMCE shall provide services to the user applications through service primitives defined for the following three SAPs: 

• TNCC-SAP for CC services; 

• TNSS-SAP for SS services; 

• TNSDS-SAP for SDS. 

NOTE: Although there are separate SAPs defined for CC and SS, the protocol description is based on the CC 
service primitives, which contain a mixture of CC and SS parameters. 

CMCE shall obtain services from the underlying voice and data MLE through the LCMC-SAP. 

There shall be one instance of the CMCE entity per TSI family within the MS. 

The CMCE is internally subdivided into four different sub-entities: 

• CC; 

• SS; 

• SDS; and 

• Protocol Control (PC). 

The information exchange between the CC and the SS sub-entities is defined in the supplementary service definitions. 
The structure is as shown in figure 14.2. 
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Fnote 1 n 



/\ 



Y 



Fnote 2 ~~\ 



ra route 

Fnote i ~~\ 



Y 



rb route 

Fnote 2 ~~\ 



Fnote 3 ~\ 



/\ 



v 



re route 

Fnote 3 ~~\ 



1..n 



Call Control 



rg route 
< > 



1..n+1 
Supplementary 
Services 



rh route 
< > 



Short Data 
Service 



D-ALERT 
D-GALL PROCEEDING 
D-GALL RESTORE 
D-GONNECT 
D-GONNECT 
D-GONNECT AGK 
D-DISGONNECT 
D-INFO 
D-RELEASE 
D-SETUP 
D-TX CEASED 
D-TX CONTINUE 
D-TX GRANTED 
D-TX INTERRUPT 
D-TX WAIT 
BREAK indication 
BUSY indication 
CLOSE indication 
CONFIGURE indication 
IDLE indication 
INFO indication 
OPEN indication 
REOPEN indication 
REPORT indication 
RESTORE confirm 
RESUME indication 



^/\ 



D-FACILITY 
BUSY indication 
CLOSE indication 
IDLE indication 
INFO indication 
OPEN indication 
REPORT indication 



_/V 



rd route 



U-ALERT 

U-CALL RESTORE 
U-CONNECT 
U-DISCONNEGT 
U-INFO 
U-RELEASE 
U-SETUP 
U-TX CEASED 
U-TX DEMAND 
ACTIVITY request 
CANCEL request 
CONFIGURE request 
RESTORE request 



\/ 



D-STATUS 
D-SDS DATA 
BUSY indication 
CLOSE indication 
IDLE indication 
INFO indication 
OPEN indication 
REPORT indication 



_/\ 



re route 



U-FACILITY 
CANCEL request 
IDENTITIES request 



\/ 



rf route 



U-STATUS 
U-SDS DATA 
CANCEL request 



V 



Protocol Control 



MLE-BREAK indication 
MLE-BUSY indication 
MLE-GONFIGURE indication 
MLE-GLOSE indication 
MLE-IDLE indication 
MLE-INFO indication 
MLE-OPEN indication 
MLE-REOPEN indication 
MLE-RELEASE indication 
MLE-REPORT indication 
MLE-RESUME indication 
MLE-UNITDATA indication 



/\ 



\/ 



ri route 



MLE-ACTIVITY request 
MLE-GANCEL request 
MLE-GONFIGURE request 
MLE-IDENTITIES request 
MLE-RELEASE request 
MLE-RESTORE request 
MLE-UNITDATA request 



N0TE1 
NOTE 2 
NOTES 



Service primitives for the TNCC-SAP are defined in clause 1 1 . 
Service primitives for the TNSS-SAP are defined in clause 12. 
Service primitives for the TNSDS-SAP are defined in clause 1 3. 

Figure 14.2: Block view of CIVICE-IVIS 
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14.2.3 Addressing rules 



In addition to the normal TSI which is used in different forms in the initial call set-up messages (ITSI, GTSI, SSI), the 
CMCE entity shall also use the call identifier for call handling. 

The call identifier shall be used as a unique reference to a call between a call participant and the SwMI. A call identifier 
is allocated at call set-up time by the SwMI and the call identifier may be changed by the SwMI by allocating a new call 
identifier to the MS for the call. Once allocated, the call identifier shall be used in subsequent call related CMCE 
messages for that call. 

The layer 3 air interface messages may contain only the SSI part of an address. The following rules define how the 
receiving entity shall, if it needs to do so, derive the MNI (i.e. convert the SSI to full ITSI or GTSI) if the MNI is not 
supplied over the air interface. 

• The SwMI shall interpret the "Called party SSI" or "Other party SSI" on received uplink messages as 
belonging to the SwMI (i.e. the "missing" MNI is the MNI of the current network). 

• The MS shall interpret the "Calling party address SSI" or "Transmitting party address SSI" on received 
downlink messages as belonging to the current SwMI (i.e. the "missing" MNI is the MNI of the current 
network). 

NOTE 1: The MNI of the SwMI (MCC and MNC) is sent in the broadcast D-MLE-SYNC PDU, refer to 
clause 18.4.2.1. 

NOTE 2: The first rule forces the MS to send the MNI over the air interface also when the called user address 
belongs to the home network of the MS and MS has migrated to a foreign network - edition 1 of the 
Dialling and Addressing Designer's Guide, TR 102 300-5 [i.l], describes a different approach which is no 
longer valid. 

NOTE 3: The second rule allows to use only SSI addressing so that all MSs in the same SwMI, independently of 
whether they are in their home or in a visited SwMI, will understand it in the same manner (for example 
group calls having participants belonging to different networks). 

NOTE 4: The supplementary service related information in U/D-FACILITY PDU or in facility information element 
may use SSI differently, refer to supplementary service definitions. 

NOTE 5: The visiting GSSI ((V)GSSI) is used only as a layer 2 address in reception and also by MM in layer 3 
PDUs in the group attachment/detachment procedures. 

• V-GSSI shall not be used as "Called party SSI" or "Other party SSI" in CMCE PDUs. 

NOTE 6: If a SwMI allocates a temporary address the MS will consider that the MNI of it is the one of the current 
SwMI. 

1 4.2.4 CC, SS and SDS sub-entities 

The CMCE model describes the protocol behaviour of CC, SS and SDS functional entities. 

14.2.4.1 CC sub-entity 

The CC process is a functional sub-entity which provides a set of procedures for the establishment, maintenance and 
release of circuit switched services. It provides support for the TETRA basic call signalling. The CC shall manage 
invocation of the SS-Access Priority. 

The CC process shall use the ra signalling route for communication with the user application (see clause 11) and the rd 
signalling route for communication with the protocol control process. The information exchange of SS related 
parameters needed for SS information exchange is not defined. 

There can be multiple instances of CC per CMCE entity. Depending on its physical capabilities an MS may be able to 
support up to four active concurrent circuit mode calls at the same time. 
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14.2.4.2 SS sub-entity 

The SS process is a functional sub-entity which provides procedures for transfer of information related to SSs. The 
transfer of SS information is either call related or call unrelated. 

The SS processes shall use the rb signalling route for communication with the user application over the TNSS-SAP (see 
clause 12) and the re signalling route for communication with the protocol control process. Internal communication 
between the CC process and the SS process is outside the scope of the present document. 

SSs related to a call in progress shall have a fixed relationship with the corresponding CC entity instance and these SS 
instances shall cease to exist after the CC instance ceases to exist. 

There shall be also a SS entity, which is not related to any calls in progress. That entity may use either a 
U/D-FACILITY PDU or any CC PDU, when appropriate, to exchange SS information between a MS and a SwMI. The 
facility field of the CC PDUs shall only be used to exchange SS information between a MS and the SwMI. 

14.2.4.3 SDS sub-entity 

The SDS process shall be a functional sub-entity which provides procedures for transfer of short data and status 
messages. The SDS entity shall also manage invocation of the SS- Access Priority for the short data PDU exchange. 

The SDS process shall use the re signalling route for communication with the user application over the TNSDS-SAP 
(see clause 13) and the rf signalling route for communication with the protocol control process. 

The SDS entity shall not be related to any call and it shall provide SDS services independently of whether the SDS 
message is directed to a user application involved in an active CC call, or not. 

There shall only be one instance of SDS entity per CMCE entity. 

14.2.5 PC sub-entity 

The PC sub-entity shall provide the following functionality: 

• PC shall act as an upwards/downwards router by discriminating the upper sub-entities within CMCE. The 

analysis of the content of the various information elements in the PDUs shall be done by the sub-entity which 
is responsible for and owns the individual elements. Outgoing PDUs shall be routed to the MLE in primitives. 



• 



PC shall ensure that there is only one mobile originated call set-up in progress at any one time by only 
allowing one CC sub-entity at a time to be actively setting up a call until SwMI allocates a call identifier to 
that call or the call set-up is discarded. 

MLE shall give indications of the progress of the PDU transmission to PC by MLE-REPORT indication 
primitives. PC shall be responsible for handling of general error procedures for the CMCE protocol. 

PC shall use the signalling routes rd, re, rf for communication with the CC, SS and SDS sub-entities and the ri 
signalling route for communication with the MLE over the LCMC-SAP. 

there shall only be one instance of PC per CMCE entity. 
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14.2.6 Internal routes 

The PDUs and local primitives are grouped per each sub-entity and internal route. 
From PC to CC on rd route: 

D-ALERT; 

D-CALL PROCEEDING; 

D-CALL RESTORE; 

D-CONNECT; 

D-CONNECT ACKNOWLEDGE; 

D-DISCONNECT; 

D-INFO; 

D-RELEASE; 

D-SETUP; 

D-TX CEASED; 

D-TX CONTINUE; 

D-TX GRANTED; 

D-TX INTERRUPT; 

D-TX WAIT; 

BREAK indication; 

BUSY indication; 

CLOSE indication; 

CONFIGURE indication; 

IDLE indication; 

INFO indication; 

OPEN indication; 

REOPEN indication; 

REPORT indication; 

RESTORE confirm; 

RESUME indication. 
From CC to PC on rd route: 

U-ALERT; 

U-CALL RESTORE; 

U-CONNECT; 

U-DISCONNECT; 

U-INFO; 
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• U-RELEASE; 

• U-SETUP; 

• U-TX CEASED; 

• U-TX DEMAND; 

• ACTIVITY request; 

• CANCEL request; 

• CONFIGURE request; 

• RESTORE request. 
From PC to SS on re route: 

• D-FACILITY; 

• BUSY indication; 

• CLOSE indication; 

• IDLE indication; 

• INFO indication; 

• OPEN indication; 

• REPORT indication. 
From SS to PC on re route: 

• U-FACILITY; 

• IDENTITIES request; 

• CANCEL request. 

NOTE 1: U/D-FACILITY PDUs are used to transport SS information, which is not related to any ongoing call or 
related to a call during SS-CC retention time after the call. 

NOTE 2: SS information, which relates to an ongoing call is transported either as a predefined element in a CC 
PDU or as a facility element in a CC or in a U/D-INFO PDU (see clause 14.7). 

From PC to SDS on rf route: 

D-STATUS; 

D-SDS-DATA; 

BUSY indication; 

CLOSE indication; 

IDLE indication; 

INFO indication; 

OPEN indication; 

REPORT indication. 
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From SDS to PC on rf route: 

• U-STATUS; 

• U-SDS-DATA; 

• CANCEL request. 



14.2.7 Intra-CMCE primitive summary 



The sub-entities inside CMCE shall be responsible for setting parameters in each PDU it is sending. These parameters 
are used in the lower layers in the transmission process. These parameters are not visible outside the MS protocol stack, 
but shall affect to the functions inside the protocol stack. 

14.2.7.1 Down link CC PDU parameters 

The following parameters shall accompany each PDU in addition to the PDU contents (SDU). The contents of the 
SDUs are defined in clause 14.7. These parameters shall be valid for rd route (see clause 17.3.4 for ri route parameters): 

• received TETRA address; 

• received address type; 

• channel change response required. 

The D-CALL RESTORE PDU should be a SDU in the RESTORE confirm primitive and the parameters used in this 
primitive shall be: 

• SDU; 

• restoration result. 

14.2.7.2 Uplink CC PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents of the PDUs 
are defined in clause 14.7. These parameters shall be valid for rd route (see clause 17.3.4 for ri route parameters): 

endpoint identifier; 

layer 2 service; 

PDU priority; 

stealing permission; 

stealing repeats flag. 

The MS shall send the U-RESTORE REQUEST PDU as an SDU in the RESTORE request primitive. 
The parameters used in this primitive shall be: 

• SDU; 

• layer 2 service; 

• PDU priority; 

• stealing permission; 

• stealing repeats flag. 
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14.2.7.3 Downlink SS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents of the PDUs 
are defined in clause 14.7. These parameters shall be valid for re route (see clause 17.3.4 for ri route parameters): 

• channel change response required; 

• received TETRA address; 

• received address type. 

1 4.2.7.4 Uplink SS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents of the PDUs 
are defined in clause 14.7. These parameters shall be valid for re route (see clause 17.3.4 for ri route parameters): 

• layer 2 service; 

• PDU priority; 

• stealing permission. 

14.2.7.5 Down link SDS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents of the PDUs 
are defined in clause 14.7. These parameters shall be valid for rf route (see clause 17.3.3 for ri route parameters): 

• received TETRA address; 

• received address type. 

14.2.7.6 Uplink SDS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents of the PDUs 
are defined in clause 14.7. These parameters shall be valid for rf route (see clause 17.3.4 for ri route parameters): 

• layer 2 service; 

• PDU priority; 

• stealing permission; 

• link identifier. 

14.2.7.7 CMCE management primitives 

14.2.7.7.0 ACTIVITY request 

The parameter used in this primitive shall be: 

• call state (see clause 17.3.9). 

14.2.7.7.1 BREAK indication 

There are no parameters associated with this primitive. 

14.2.7.7.1a BUSY indication 

There are no parameters associated with this primitive. 
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14.2.7.7.2 CANCEL request 

The parameter used in this primitive shall be: 

• handle. 

14.2.7.7.3 CLOSE indication 

There are no parameters associated with this primitive. 

14.2.7.7.4 CONFIGURE indication 

The parameters used in this primitive shall be: 

• endpoint identifier; 

• endpoint status. 

14.2.7.7.5 CONFIGURE request 

The parameters used in this primitive shall be: 

• add temporary GSSI; 

• circuit mode type (see clause 14.8.2); 

• channel change accepted (see clause 17.3.9); 

• leave assigned channel; 

• delete temporary GSSI; 

• encryption flag; 

• call identifier; 

• endpoint identifier; 

• simplex/duplex; 

• slots per frame; 

• switch U-plane on/off; 

• Tx grant. 

14.2.7.7.6 IDENTITIES request 

The parameter used with this primitive shall be: 

• hst of attached GSSIs; 

• Ust of detached GSSIs. 

14.2.7.7.6a IDLE indication 

There are no parameters associated with this primitive. 
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14.2.7.7.6b INFO indication 

The parameters used with this primitive shall be: 

• broadcast parameters (see clause 17.3.9); 

• subscriber class match (see clause 17.3.9). 

14.2.7.7.7 OPEN indication 

There are no parameters associated with this primitive. 

14.2.7.7.8 REOPEN indication 

There are no parameters associate with this primitive. 

14.2.7.7.9 REPORT indication 

The parameter used in this primitive shall be: 

• transfer result. 

14.2.7.7.10 RESUME indication 

There are no parameters associated with this primitive. 
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1 4.3 Overview of services required by the CIVICE 

In order to transfer messages over the air interface, CMCE shall use the services of the MLE, which in turn shall rely on 
the service from underlying layers. The services required from MLE shall be as described in clause 17. 

14.4 CIVICE protocol states 

CMCE shall comprise 4 sub-entities each of them having a separate state transition diagram as shown in figures 14.3, 
14.4, 14.5 and 14.6. 

Only the main states are shown. 

14.4.1 States for PC 



After Start Up 




MLE-CLOSE indication / \ 



\/ 



IVILE-OPEN indication 



All other PDUs 
and primitives 




Figure 14.3: State transition diagram for the PC sub-entity 



14.4.1.1 



CLOSED 



This state exists after an MLE-CLOSE indication primitive has been received from the MLE indicating that access to 
communication resources is no longer allowed and the PC sub-entity shall inform the CC, SS and SDS sub-entities with 
CLOSE indication primitives. The PC sub-entity shall also enter state CLOSED after initial start up. 



14.4.1.2 



OPEN 



This is the normal state and indicates that a communication path to a peer entity is open. It is set after an MLE-OPEN 
indication primitive has been received from the MLE. When PC receives a MLE-OPEN indication primitive and goes to 
state OPEN, the CC, SS and SDS sub-entities shall be informed with OPEN indication primitives. 
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14.4.2 States force 



TNCC-COMPLETE request 
TNCC-SETUP response (indiv) 
TNCC-TX request 
D-INFO 



(See also SUB-STATES) 




D-SETUP 



NOTE 1 : The TNCC-RELEASE request primitive transitions from the state "ANY STATE" are not applicable for the 

"CALL COLLISION" state. 
NOTE 2: The selection of the TNCC-RELEASE request primitive transition from the state "ANY STATE" is 

dependent on the need for sending disconnection message over the air interface, refer to 

clauses 14.5.1.1.3 and 14.5.2.1.3. 
NOTE 3: The TNCC-RELEASE request primitive transitions from CALL COLLISION state present interactions 

between two call control instances and show a simplified view, refer to clauses 14.5.1.1.3 and 14.5.2.1.3. 

Figure 14.4: State transition diagram for the CC sub-entity 
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A farther subdivision of the main states MT-CALL-SETUP and CALL- ACTIVE belonging to the CC sub-entity may 
be considered as detailed in figures 14.5 and 14.6. 



D-RELEASE 
T308 time out 




D-RELEASE 
D-DISCONNECT 
CLOSE indication 
REOPEN indication 



D-TX GRANTED 
D-TX CONTINUE 



D-INFO 



Figure 14.5: Sub state transition diagram for thie CALL- ACTIVE state 
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D-RELEASE 
D-DISCONNECX 



TNCC-RELEASE rei 




D-SETUP 
D-INFO 



TNCC-RELEASE req 




Txx TIMEOUT 
TNCC-RELEASE req 



D-SETUP 
TNCC-TX req 



14.4.2.1 



Figure 14.6: Sub state transition diagram for the IVIT-CALL-SETUP state 



IDLE 



This is the normal state when no calls exist and indicates that the CC sub-entity is available to handle a call set-up. This 
is the state that CC shall enter after initial start up. 

NOTE: Any transition to or from the IDLE state should be accompanied with the generation of an ACTIVITY 
request primitive (see clause 14.2.7.7.0), containing the appropriate call state, to the PC entity. 



14.4.2.2 



MO-CALL-SETUP 



This state exists when a MS originated call set-up has been initiated but the call has not been established. It exists after a 
U-SETUP PDU has been sent as the result of the receipt of a TNCC-SETUP request primitive until a D-CONNECT 
PDU is received indicating that the call set-up is successful. If the call set-up is unsuccessful or the user application 
disconnects the call the CC sub-entity shall leave this state. 



14.4.2.3 



MT-CALL-SETUP 



This state exists during a call set-up where the CC sub-entity is the call terminating CC sub-entity. It exists after the 
receipt of a D-SETUP PDU, until the receipt of a D-CONNECT ACKNOWLEDGE PDU, for point-to-point calls only, 
or receipt of a TNCC-SETUP response primitive for point-to-multipoint calls only. The MT-CALL SETUP state is also 
left if the call set-up is unsuccessful, or if the user application rejects the call. 
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14.4.2.4 CALL ACTIVE 

This state exists when the call has been established. 

NOTE: Transitions between the ACTIVE RX and ACTIVE TX sub-states should be accompanied with the 
generation of an ACTIVITY request primitive (see clause 14.2.7.7.0), containing the appropriate call 
state, to the PC entity. 



14.4.2.5 



CALL DISCONNECT 



This state exists when an established call is in the progress of disconnecting. It exists after the receipt of 

a TNCC-RELEASE request primitive from the user application, or if a timer initiated disconnection occurs, until either 

a D-RELEASE PDU is received, or the call disconnect timer expires. 



14.4.2.6 



WAIT 



The state exists if there is a temporary interruption to the call. The CC shall enter this state upon receipt of 

a D-TX WAIT PDU and remain in this state until a D-TX CONTINUE PDU or D-TX GRANTED PDU is received, or 

the call is disconnected. 

14.4.3 States for SS 

There shall only exist 2 general generic states for the SS sub-entity as shown in figure 14.7. Each individual service 
shall then have its own state transition diagrams associated with its protocol. 

D-FACILITY 
FACILITY indication 
OPEN indication 
CLOSE indication 
BREAK indication 



TNSS-SERVICE response 
TNSS-SERVICE request 
TNSS-INFO response 
TNSS-INFO request 




REPORT indication 
CLOSE indication 
Txxx time out 



D-FACILITY 
FACILITY indication 




Figure 14.7: State transition diagram for the SS sub-entity 
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14.4.4 States for SDS 

There shall only exist 2 generic states for the SDS sub-entity as shown in figure 14.8. 



D-SDS DATA 
D-STATUS 
OPEN indication 
CLOSE indication 



TNSDS-STATUS request 
TNSDS-UNITDATA requesi 




REPORT indication 
CLOSE indication 
Txxx time out 



D-SDS DATA 
D-STATUS 




Figure 14.8: State transition diagram for the SDS 



14.5 Procedures 



In this protocol the routing of PDUs and primitives is implicit by the PDU and primitive name as defined in clause 14.2. 
The timers in the following procedures are: 

• started - meaning that the timer shall start to measure time as indicated in the parameter value T3xx 
independently of the current timer count; or 

• stopped - meaning that the timer shall be stopped at the current timer count; or 

• reset - meaning that the timer count shall be set to its initial value, be it zero or parameter value T3xx. 

Depending on timer T3xx the starting value shall either be pre-defmed or dynamically set by air interface protocol 
procedures. 

NOTE 1 : In IDLE state all timers T3xx are stopped and whenever a timer is started it will get a proper value as 
stored, or from a PDU as appropriate. 

NOTE 2: There is no call identifier associated to a CC instance in IDLE state. 
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14.5.1 Individual CC procedures 



The CC procedures handled by the CC sub-entity shall be applicable for both speech and data circuit mode calls. 
Individual speech and data circuit mode calls shall be set-up as point-to-point calls. The specification shall be applicable 
for the procedures and states that reside in the MS. 



1 4.5.1 .1 Call set-up procedures 

Call set-up procedure examples are presented in figures 14.9 and 14.10. 

pc mie SwMI mie 



user CC 

tncc_setup req 



Start T303 



tncc_proceed irid^ 
■* Stop T303 
Start T302 



tncc_nolify ind 
" (Start T302) 



lncc_alert ind 
" Start T302 



tncc_setup con^ 
Stop T302 
Start T310 



U- SETUP 



report ind 



report ind 
report ind 



D-CALL 



PROCEEDING 



D-INFO 



D-ALERT 



D-CONNECT < 



configure req 



mle_unitdata req 
_mle_report ind 



, mle_report ind 



mle_report ind 



. mle_unitdata ind 



. mle_unitdata ind 



mle_unitdata in d ^ 



mie unitdata ind 



mle_configure req 



pc 



mie unitdata ind . 


D-SETUP 


tncc_setup ind 


mle_unitdata req 

mle_report ind 
mle_report ind 
mie report ind ^ 


U-ALERT 


^ tncc_setup_res 


^tncc_complete rec 


report ind 


report ind 


report ind "^ 


mle_unitdata req 


U-CONNECT 


Start T301 

tncc_complete con 

Stop T301 ^ 
Start T310 


report ind 


mie report ind 


mie report ind 


report ind ^ 


mie report ind ^ 


report ind "^ 


mie unitdata ind ^ 


D-CONNECT 


mle_configure req 


acknowledge'' 

. configure req 







Figure 14.9: Individual call set-up scenario using on/off hook signalling 
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user cc 

lncc_setup req 



Start T303 



j lncc_proceed in d 
Stop T303 
Start T302 



Jncc_setup cori_ 
Stop 1302 
Start T310 



pc 



mie SwMI 



mie 



U- SETUP 



report ind 



report ind 
report ind 



► mle_unitdata req 

mle_report ind 

mle_report ind 

mle_report ind 



D-CALL 



, mle_unitdataind 



PROCEEDING 



, mle_unitdata ind i- 
D-CONNECT ^ 



configure req 



mle_configure req^ 



pc 



mie unitdata ind ^ 

mle_unitdata req^ 
mie report ind . 


D-SETUP 


tncc_setup ind ^ 


^ U-CONNECT 


tncc setup res 


Start T301 

tncc_complete ind 

Stop T301 
Start T310 


report ind 


mie report ind 
mie report ind . 

mie unitdata ind ^ 


report ind 


report ind 


D-CONNECT 


.mie configure req 
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Figure 14.10: Individual call set-up scenario using direct set-up signalling 



Incoming call 



Notification of the arrival of an incoming call to the CC sub-entity shall be made by the reception of a D-SETUP PDU 
which shall be delivered to the user application in a TNCC-SETUP indication primitive via the TNCC-SAP. If the user 
application can support the call it shall immediately return a TNCC-SETUP response primitive otherwise it shall return 
a TNCC-RELEASE request primitive (see clause 14.5.1.1.5). 

On receipt of a D-SETUP PDU the CC sub-entity shall enter state MT-CALL-SETUP and take the following actions, 
which are dependent upon the information contained within the D-SETUP PDU: 

• the call identifier shall be used as the reference to this call in subsequent PDUs during the call; 

• it shall be indicated to the called MS in the D-SETUP PDU if on/off hook signalling or direct set-up signalling 
is used for this call set-up; 

• if on/off hook signalling is requested and the CC receives a TNCC-SETUP response primitive indicating that 
the called user application has accepted on/off hook signalling, the CC shall send a U- ALERT PDU indicating 
that the called party is alerted, see figure 14.9 right hand side. The CC sub-entity shall remain in state 
MT-CALL-SETUP; 

• when on/off hook signalling is used and the CC receives a TNCC-COMPLETE request primitive indicating 
that the called user application has answered, the CC shall send a U-CONNECT PDU and start timer T301. 
The CC sub-entity shall remain in state MT-CALL-SETUP. Upon receipt of a D-CONNECT 
ACKNOWLEDGE PDU, the CC shall inform the user application with a TNCC-COMPLETE confirm 
primitive, enter state CALL- ACTIVE, stop timer T301 and start timer T310, see figure 14.9 right hand side. 
The D-CONNECT ACKNOWLEDGE PDU shall contain an indication as to which party is permitted to 
transmit. The CC sub-entity shall send a CONFIGURE request primitive for lower layer configuration; 

• in a duplex call the SwMI shall grant permission to talk in the D-CONNECT ACKNOWLEDGE PDU; 
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if direct set-up signalling is used and the CC receives a TNCC-SETUP response primitive indicating that the 
called user application has accepted direct call set-up signalling, the CC shall send a U-CONNECT PDU 
indicating that the MS is ready for immediate communication, and shall start timer T301. Upon receipt of the 
U-CONNECT PDU the SwMI should send a D-CONNECT ACKNOWLEDGE PDU in return. The CC 
sub-entity shall then inform the user application with a TNCC-COMPLETE indication primitive and shall 
enter state CALL- ACTIVE, stop timer T301 and start timer T310, see figure 14.10 right hand side. The 
D-CONNECT ACKNOWLEDGE PDU shall contain an indication as to which party is permitted to transmit. 
The CC sub-entity shall send a CONFIGURE request primitive for lower layer configuration; 

if transmission is not granted but the D-CONNECT ACKNOWLEDGE PDU contains an indication that the 
MS is allowed to request transmission permission, the CC shall follow the transmission control procedures 
outlined in clause 14.5.1.2.1; 

where the called MS is unable to accept the request for a basic service, it may according to the rules stated 
below, offer a different basic service to the calling party. The offered value shall be indicated in the 
U-CONNECT or U-ALERT PDU. Where the called MS is unable to offer a different service according to the 
rules below then the call shall be rejected using a U-DISCONNECT PDU as defined in clause 14.5.1.1.5, 
e.g. if circuit mode data is requested but the terminal cannot support data. 

for circuit mode unprotected bearer services: 

if 28,8 kbit/s requested, 21,6 kbit/s, 14,4 kbit/s or 7,2 kbit/s may be offered; 

if 21,6 kbit/s requested, 14,4 kbit/s or 7,2 kbit/s may be offered; 

if 14,4 kbit/s requested, 7,2 kbit/s may be offered, 
for circuit mode protected (low) bearer services: 

if 19,2 kbit/s requested, 14,4 kbit/s, 9,6 kbit/s or 4,8 kbit/s may be offered; 

if 14,4 kbit/s requested, 9,6 kbit/s or 4,8 kbit/s may be offered; 

if 9,6 kbit/s requested, 4,8 kbit/s may be offered; 

if interleaving depth N = 8 requested, N = 4 or N = 1 may be offered; 

if interleaving depth N = 4 requested, N = 1 may be offered, 
for circuit mode protected (high) bearer services: 

if 9,6 kbit/s requested, 7,2 kbit/s, 4,8 kbit/s or 2,4 kbit/s (high) may be offered; 

if 7,2 kbit/s requested, 4,8 kbit/s or 2,4 kbit/s (high) may be offered; 

if 4,8 kbit/s requested, 2,4 kbit/s (high) may be offered; 

if interleaving depth N = 8 requested, N = 4 or N = 1 may be offered; 

if interleaving depth N = 4 requested, N = 1 may be offered. 

if the called MS is requested to support a duplex call and is unable to do so, then it shall offer a simplex call by 
setting the simplex/duplex element accordingly in either the U-ALERT or U-CONNECT PDU; 

if the called MS is requested to use direct call set-up and it is unable to support this, but does support on/off 
hook signalling, then it shall offer this service by sending the U-ALERT PDU; 

if the called MS is requested to use on/off hook signalling and is unable to support this, but does support direct 
call set-up, then it shall offer this service by setting the hook method element accordingly in the U-CONNECT 
PDU; 

if the called user application during the call set-up cannot continue to support of the call for other reasons that 
those stated above the request for call set-up shall be rejected by issuing a TNCC-RELEASE request primitive. 
The request to release the call set-up shall be mapped to a U-DISCONNECT PDU and follow the procedure 
defined in clause 14.5.1.3. 
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During the call set-up phase, the SwMI may send the D-INFO PDU containing a new value for T301 to prolong the call 
set-up time. If the CC in the called MS receives an D-INFO PDU containing a Call time-out, set-up phase element the 
CC shall start timer T301 using the specified value. 

14.5.1.1.2 Outgoing call 

To initiate the call establishment, the user application shall transfer a TNCC-SETUP request primitive across the TNCC 
SAP to the CC sub-entity. The TNCC-SETUP request primitive shall be handled by a CC sub-entity instance that is in 
state IDLE. 

The CC shall select a PDU priority based on the requested access priority value as defined in clause 14.5.6.2. The CC 
shall convert the TNCC-SETUP request primitive into a corresponding U-SETUP PDU and send it. The CC sub-entity 
shall then enter the MO-CALL-SETUP state and start timer T303. 

The following describes the normal call set-up procedures: 

• The progress of the transmission of the U-SETUP PDU may be reported to the CC in one or more REPORT 
indication primitives. If the PDU transfer has failed, the CC shall stop timer T303, inform the user application 
with a TNCC-RELEASE indication primitive and return to state IDLE. 

• The SwMI may respond to the receipt of the U-SETUP PDU with a D-CALL PROCEEDING PDU indicating 
that the SwMI has received all information concerning the call set-up necessary to effect the call 
establishment. On reception of the PDU, the CC shall inform the user application with a TNCC-PROCEED 
indication primitive. In the case where On/Off Hook Signalling is requested or the called user application 
selects that method and alerting information is ready at the time when the D-CALL PROCEEDING PDU 
should have been sent, the SwMI may respond with a D-ALERT PDU instead of the D-CALL PROCEEDING 
PDU. Also if the call through connection is ready at the time when the D-CALL PROCEEDING PDU should 
have been sent, the SwMI may send a D-CONNECT PDU instead. On receipt of any of the above PDUs, 
Timer T303 shall be stopped, see figure 14.9 left hand side. 

• The D-CALL PROCEEDING, D-ALERT or D-CONNECT PDU shall contain a Call Identifier which shall be 
used as the reference to this call in subsequent PDUs for the duration of the call. 

• The D-INFO PDU shall not be used to allocate a call identifier. 



• 



On reception of the DU-CALL PROCEEDING PDU the CC shall start timer T302, see figure 14.9 left hand 
side. The CC sub-entity shall remain in state MO-CALL-SETUP. 

• If on/off hook signalling is requested and the CC receives a D-ALERT PDU, the CC shall inform the user 
application by issuing a TNCC-ALERT indication primitive. 

• On reception of a D-ALERT PDU, the timer T302 shall be started using the specified value, see figure 14.9 
left hand side. 

• During the call set-up phase, the SwMI may send the D-INFO PDU containing a new T302 to prolong the call 
set-up time. Upon reception of a D-INFO PDU containing Call time out, set-up phase element, the timer T302 
shall be started using the specified value. 

• In a duplex call the SwMI shall grant permission to talk in the D-CONNECT PDU. 

• When a D-CONNECT PDU is received, the CC shall send a CONFIGURE request primitive for lower layer 
configuration and inform the user application with a TNCC-SETUP confirm primitive and enter state 
CALL- ACTIVE. The timer T302 shall be stopped, and timer T310 shall be started, see figure 14.9 left hand 
side. The D-CONNECT PDU shall contain an indication which party is permitted to transmit. 

• If transmission is not granted but the D-CONNECT PDU contains an indication that the MS is allowed to 
request transmission permission it shall follow the transmission control procedures defined in 

clause 14.5.1.2.1; 

• Where the D-CALL PROCEEDING, D-CONNECT or the D-ALERT PDU indicates that the offered service is 
different to the one requested, and if the service offered is acceptable to the user application, the call shall 
continue. If the service is not acceptable, then the user application shall disconnect the call and the CC shall 
enter IDLE state, refer to clause 14.5.1.3. 
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EXAMPLE: If the user application has requested a 28,8 kbit/s circuit mode data, but considers that any data rate 
equal to or greater than 14,4 kbit/s is acceptable, then if a data rate of 14,4 kbit/s is offered the call 
shall continue. If a data rate of less than 14,4 kbit/s is offered (i.e. 7,2 kbit/s) then the user 
application shall disconnect the call. 

NOTE: Handling of the TNCC-SETUP request primitive may be affected by the MS being active in a MM 
procedure, this being indicated to CC from MLE via the MLE-BUSY indication primitive, refer to 
clause 18.3.5.4. The exact nature of the interaction between MM/MLE and CC is outside the scope of this 
part of the present document but it is recommended that CC not accept a TNCC-SETUP request primitive 
while MM is busy. 

14.5.1.1.3 Colliding calls 

Call collisions can occur when both the SwMI and the MS simultaneously send a D/U-SETUP PDU. Two call set-ups 
are colliding when a D-SETUP PDU is received within the window where the CC waits for a Call Identifier from the 
SwMI after a U-SETUP PDU has been issued. If this occurs and the MS cannot support more concurrent calls, the MS 
shall behave as follows: 

• if the MS wishes to keep its own call attempt then it shall respond to the incoming call with a 
U-DISCONNECT PDU with a disconnect cause "called party busy"; or 

• if the MS wishes to accept the incoming call then the CC shall accept the call as defined in clause 14.5.1.1.1. 
The CC shall also send a CANCEL request primitive to the lower layers to cancel the sending of the U-SETUP 
PDU. If the lower layers indicate that the PDU has already been completely sent, then the CC shall send 

a U-DISCONNECT PDU for its own call set-up. 

Another case of call colUsion may sometimes be detected and resolved by the SwMI. If the colliding calls are call set-up 
attempts between the same user applications and the requested basic services are the same, then the SwMI may merge 
the calls. The SwMI should inform both parties by a D-CONNECT PDU with an amalgamation indication that the calls 
are merged together, see the call ownership element. The CC should pass this information on to the application in the 
TNCC-SETUP confirm primitive. 

14.5.1.1.4 Unsuccessful call set-up 

Unsuccessful call set-up shall refer specifically to those instances where a circuit mode connection was not successfully 
established. It shall not refer to call disconnection or call rejection. If a PDU is not responded to prior to the expiry of 
the corresponding timer the procedure in clause 14.5.1.3.4. shall apply. All timers available are listed in clause 14.6. 

When CC receives a REPORT indication primitive, indicating that the lower layers have not been successful (failed 
transfer) in the sending of any of the call set-up PDUs, then the CC sub-entity shall return to state IDLE and shall 
inform the user application with a TNCC-RELEASE indication primitive accompanied with a cause of the 
disconnection. 
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14.5.1.1.5 
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Figure 14.11 : Individual call set-up phase - called user application rejects the call 

If the user application cannot accept an incoming call as defined in 14.5.1.1.1, it shall immediately transfer 
a TNCC-RELEASE request primitive to the CC sub-entity. The CC sub-entity shall send a U-DISCONNECT PDU 
along with the disconnection cause "Call Rejected by the called party", see figure 14.1 1. In case the rejection results 
from unsupported encryption flag state the disconnect cause shall be "Called party does not support encryption" or 
"Called party requires encryption". The CC sub-entity shall then change to state IDLE. 

NOTE: If the SwMI sends the D-RELEASE PDU as the first response to the calling MS, then it should contain 
the dummy call reference. 

For the busy case refer to clause 14.5.6.5.3. 

1 4.5.1 .2 Call maintenance procedures 

The call maintenance procedures described in this clause may be applied when the MS is in states MO-CALL SETUP, 
MT-CALL SETUP or CALL- ACTIVE. The main state CALL- ACTIVE can comprise several sub-states which are 
presented in informative figure 14.5. 

NOTE: The D-INFO PDU can be used for other purposes than those defined in the protocol specifications 
contained in the present document. 
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14.5.1.2.1 



Transmission control procedures 



Only the transmission control procedures defined in clauses 14.5.1.2.1 c) and d) shall apply in duplex call. In a duplex 
call the SwMI shall grant permission to talk to both parties in the D-CONNECT and D-CONNECT ACKNOWLEDGE 
PDUs. 
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NOTE: For the purposes of clarity, only one instance of mle_report is shown. 

Figure 14.12: Individual call request-to-transmit 

a) Request-to-Transmit 

The SwMI shall fully control which MS is allowed to transmit. To facilitate this the MS shall request permission to 
transmit from the SwMI and shall receive a permission to transmit before the MS may begin a circuit mode U-plane 
transmission. If the SwMI allows, in a "transmission request permission" element, then the MS may request a 
permission to transmit even if the other party is already transmitting. In this case the SwMI should normally wait for 
that party to finish the transmission before granting the other user application. Pre-emptive priority requests are dealt 
with in clause 14.5.1.2.1 f). 

If on/off hook signalling is used, the normal mode of operation shall be that the called MS shall be given permission to 
transmit by setting the transmission grant element accordingly in the D-SETUP PDU. However, if desired, the calling 
MS can ask for permission to transmit by setting the "request to transmit" bit accordingly in the U-SETUP PDU. This is 
deah with in clauses 14.5.1.1.1 and 14.5.1.1.2. 
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If direct set-up signalling is used, the normal mode of operation shall be that the calling MS shall be given the 
permission to transmit. However the calling user application may in the U-SETUP PDU allow the called user 
application to request the permission to transmit first by setting the "request to transmit" bit accordingly in the 
U-SETUP PDU. 

When a user application within a call wants to transmit, a TNCC-TX request primitive shall be sent to the CC via the 
TNCC-SAP. The CC shall send this request in a U-TX DEMAND PDU, see figure 14.12. The TX demand priority 
should be set to low or high priority, unless this is a pre-emptive request, see clause 14.5.1.2.1 f). 

The progress of the transmission of the U-TX DEMAND PDU shall be given locally to the CC in one or more REPORT 
indication primitives. If the CC receives a REPORT indication primitive with a failed transmission indication as 
a response to the sending of the U-TX DEMAND PDU the CC shall inform the user application by 
a TNCC-TX confirm primitive. 

If a user application wants to withdraw its request-to-transmit before it has been granted, a TNCC-TX request primitive 
shall be issued to the TNCC-SAP. The CC shall send this request in a U-TX CEASED PDU or the previous request 
should be cancelled locally if still possible. The CC shall send the U-TX CEASED PDU with the stealing permission 
set to "immediate stealing" and stealing repeats flag set, so that the permission to transmit will be released immediately 
if allocated. 

b) Response to Request-to-Transmit 

During the call set-up phase. These procedures are dealt with in clauses 14.5.1.1.1 and 14.5.1.1.2. The MS given 
permission to transmit shall start timer T3 1 1 . 

During a call in progress and when SwMI has decided which MS shall be given permission to transmit, the SwMI shall 
send a D-TX GRANTED PDU to the granted MS with the transmission grant element set to "transmission granted". 
The CC sub-entity shall send this information further on to the user application in a TNCC-TX confirm primitive. The 
other MS involved in the call shall also be informed with a D-TX GRANTED PDU indicating that transmission has 
been granted to another user. This CC sub-entity shall send this information further on to the user application in a 
TNCC-TX indication primitive, see figure 14.12. 

If the SwMI rejects the transmission request this shall be indicated to the MS concerned by the "transmission not 
granted" parameter value in the D-TX GRANTED PDU. 

If the SwMI places the transmission request in a queue this shall be indicated to the MS concerned by the "transmission 
request queued" parameter value in the D-TX GRANTED PDU. The MS can then assume that the request-to-transmit 
will be held in the queue until it is either granted by the SwMI or withdrawn by the MS, or the MS receives 
a D-TX GRANTED PDU containing the "transmission not granted" parameter value. 

On reception of a D-TX GRANTED PDU indicating "transmission granted" or "transmission granted to another user", 
the CC sub-entity shall issue a CONFIGURE request primitive. The primitive shall carry as a parameter whether the 
transmit permission has been granted to this MS and a parameter to switch the U-Plane on. The MS given permission to 
transmit shall start timer T31 1. 

Though the MS shall switch to U-Plane receive if it receives a "transmission granted to another user" response to its 
transmission request, the MS shall require an explicit response to its transmission request: one of "transmission 
granted", "transmission not granted" or "transmission queued". 

If the CC sends a U-TX DEMAND PDU whilst the other MS is transmitting, then the SwMI should normally wait for 
that party to finish the transmission (identified by the receipt of a U-TX CEASED message) before granting 
transmission to the other user application. On receipt of the U-TX DEMAND PDU, the SwMI may send 
a D-TX GRANTED PDU indicating whether the request-to-transmit is queued or rejected. Pre-emptive requests are 
dealt with under clause 14.5.1.2.1 f). 

The SwMI shall not send an unsolicited D-TX GRANTED PDU but it is recognized that a race/error condition may 
result in the MS receiving one. The CC may choose to follow an unsolicited individually addressed D-TX GRANTED 
PDU indicating "transmission granted" but if the CC does not want to transmit/send data then it shall use the 
U-TX CEASED PDU, as it does normally at the end of a speech or data item, to reject the transmission grant. 
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c) Permission to Transmit witlndrawn 



The SwMI may decide to interrupt transmission when resources are required for another call or when the SwMI 
requires that the call should temporarily pause. In this case the SwMI should send a D-TX WAIT PDU to each MS 
(permitting or denying transmission requests according to the "transmission request permission" element). Upon receipt 
of the D-TX WAIT PDU, the CC sub-entity shall send a TNCC-TX indication primitive to the user application 
indicating that the transmission is waiting. The CC shall stop timer T3 11 if activated, enter state WAIT and send 
a CONFIGURE request primitive to switch the U-Plane off The MSs shall accept any layer 2 channel assignment and 
await further instructions on the channel that they have been directed to. 

If a request-to-transmit has been queued at the time when the D-TX WAIT PDU is received, the MS shall be allowed to 
withdraw its request-to-transmit by means of the U-TX CEASED PDU as described in clause 14.5.1.2.1 e). 

If the SwMI sends a D-TX WAIT PDU because it wishes to use an assigned channel for another call, it shall send a 
layer 2 channel assignment with the D-TX WAIT PDU directing the MS to a signalling channel other than the assigned 
channel. This is to prevent the change in usage marker associated with re-allocation of the assigned channel to the other 
call causing the waiting MS to drop the interrupted call. 

d) Permission to Continue witin witindrawn call 

When the SwMI has decided that the call can continue, the SwMI should send either a D-TX CONTINUE PDU or 
a D-TX GRANTED PDU to each MS. When the CC sub-entity receives the notification of the continuation of the call 
in a D-TX CONTINUE or D-TX GRANTED PDU it shall return to state CALL- ACTIVE. 

The D-TX CONTINUE PDU shall contain an indication (the continue element) to specify whether the same 
transmission permission applies as at the time of the interruption. If the continue element is set to "continue", and if the 
MS was either transmitting or receiving traffic when it received the D-TX WAIT PDU, then the CC sub-entity shall 
send a CONFIGURE request primitive to switch the U-plane on and to accept the channel change if requested. The MS 
granted permission to transmit shall start timer T311. If the continue element is set to "not continue", or if the MS was 
neither transmitting nor receiving traffic when it received the D-TX WAIT PDU, then the U-plane shall not be switched 
on and the MS shall assume that any previous transmission permission no longer applies. 

If the D-TX CONTINUE PDU contains an indication that the MS is allowed to request transmission permission, it may 
follow the transmission control procedures described in clause 14.5.1.2.1 a). 

There are three cases as follows: 

1) if no MS was granted transmission at the time when the SwMI sent the D-TX WAIT PDU, or if an MS was 
granted transmission at the time of the D-TX WAIT PDU but the SwMI does not wish that transmission to 
continue, then either a D-TX CONTINUE PDU with the continue element set to "not continue" or 

D-TX GRANTED PDU with transmission grant element set to "not granted" shall be sent individually to both 
MSs in the call. The CC shall accept any layer 2 channel allocation. All CC sub-entities shall return to state 
CALL-ACTIVE but the U-plane shall not be switched on and the MS shall assume that any previous 
transmission permission no longer appUes. If the D-TX CONTINUE PDU or D-TX GRANTED PDU contains 
an indication that the MS is allowed to request transmission permission, it may follow the transmission control 
procedures described in clause 14.5.1.2.1 a). 

2) If there was at least one MS granted transmission at the time when the SwMI sent the D-TX WAIT PDU, and 
if the SwMI wishes the transmission to continue, then either a D-TX CONTINUE PDU with the Continue 
element set to "continue" or D-TX GRANTED PDU with transmission grant element set to "transmission 
granted" or "transmission granted to another" shall be sent individually to both MSs and the CC shall accept 
any layer 2 channel allocation. If a D-TX CONTINUE PDU with the Continue element set to "continue" is 
sent, it shall give the earlier granted MS permission to continue transmission. The MS granted permission to 
transmit shall start timer T31 1. All CC sub-entities shall return to state CALL ACTIVE and shall send a 
CONFIGURE request primitive to the lower layers to switch the U-plane on. 
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3) If there was one MS granted transmission at the time when the SwMI sent the D-TX WAIT PDU but the 

SwMI wishes to give the transmission permission to the other party or if no MS was granted transmission at 
the time when the SwMI sent the D-TX WAIT PDU and the SwMI wishes to give the transmission permission 
now to another party, the SwMI may first send a D-TX CONTINUE PDU with the Continue element set to 
"not continue" individually to both MSs. A D-TX GRANTED PDU shall then be sent as an individual 
message to the granted MS with information element transmission grant set to "transmission granted" and with 
information element transmission grant set to "transmission granted to another user" to not-granted MS (if 
any). When receiving either D-TX CONTINUE or D-TX GRANTED PDU the CC sub-entity shall return to 
state CALL- ACTIVE. In addition when receiving D-TX GRANTED PDU CC shall send a CONFIGURE 
request primitive to the lower layers to switch the U-plane on. 

If the MS is in state WAIT and it receives a D-TX GRANTED PDU then it shall obey the instruction in the 
D-TX GRANTED PDU. 

e) End of Transmission 

At the end of a transmission, the user application shall send a TNCC-TX request primitive to the TNCC-S AP indicating 
ceased transmission. The CC sub-entity shall send this information in a U-TX CEASED PDU, remain in state 
CALL- ACTIVE and stop timer T311. The CC shall send the U-TX CEASED PDU with the steaHng permission set to 
"immediate stealing" and the stealing repeats flag set. Upon receipt of the U-TX CEASED PDU, the SwMI may send 
a D-TX CEASED PDU to each MS informing them that the transmission has now ceased. 

Upon reception of a D-TX CEASED PDU, the CC shall send this information further on to the user application in a 
TNCC-TX indication primitive (transmission ceased). The CC sub-entity shall send a CONFIGURE request primitive 
to the lower layers to switch the U-Plane off. 

Also, if the CC that is sending the U-TX CEASED PDU receives a REPORT indication primitive of either successful or 
unsuccessful transmission of that PDU by the lower layers, then it shall behave as if it had received a D-TX CEASED 
PDU i.e. it shall send a TNCC-TX indication primitive (transmission ceased) to the user application and shall send 
a CONFIGURE request primitive to the lower layers to switch the U-Plane off 

If there was a request for transmission already queued in the SwMI when the U-TX CEASED PDU was received, then 
the SwMI should send a D-TX GRANTED PDU to each MS as described in clause 14.5. L2.1 b), without sending an 
explicit D-TX CEASED PDU. The CC sub-entity shall send a CONFIGURE request primitive to the lower layers to 
indicate the change in the transmit permission. 

NOTE: The End of Transmission procedure is not valid for a duplex call. 

The SwMI shall not send an unsolicited D-TX CEASED PDU but it is recognized that a race/error condition may result 
in the MS receiving one. If CC receives an unsolicited D-TX CEASED PDU it shall send this information further on to 
the user application in a TNCC-TX indication primitive (transmission ceased and shall send a CONFIGURE request 
primitive to the lower layers to switch the U-Plane off. 

f) Stop Transmission order 

If, during the course of a transmission, a MS wishes to interrupt the transmitting MS, it shall send a U-TX DEMAND 
PDU indicating the wanted level of pre-emptive priority in the TX demand priority element. If the SwMI supports 
transmission interruption, it shall then send a D-TX INTERRUPT PDU to the MS that currently has the permission to 
transmit. Upon reception of a D-TX INTERRUPT PDU, the CC shall stop transmission and remain in state 
CALL- ACTIVE, stop timer T311, send a TNCC-TX indication primitive to the user application indicating transmission 
interrupt and send a CONFIGURE request primitive to lower layers to indicate the loss of transmit permission. The 
SwMI should then send a D-TX GRANTED PDU to the requesting MS indicating that the permission to transmit has 
been awarded as described in clause 14.5.1.2.1 b). 

The D-TX INTERRUPT PDU shall indicate that transmission is granted to another user and then the MS shall switch to 
U-plane reception. Otherwise, if there is a delay before the pre-emptive priority transmission, the SwMI may indicate 
"transmission not granted" in the D-TX INTERRUPT PDU. Then the MS shall switch the U-plane off and wait for a 
D-TX GRANTED PDU. 
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g) Expiry of timer T31 1 ; call transmission timer 



Upon expiry of timer T3 1 1 , CC shall remain in state ACTIVE, send a TNCC-TX indication primitive to the user 
application and a U-TX CEASED PDU to the peer entity. The CC shall send the U-TX CEASED PDU with the stealing 
permission set to "immediate stealing" and stealing repeats flag set. 

14.5.1.2.2 Call status information procedures 

The D-INFO PDU can be used for carrying call status messages from SwMI to the MS. When a D-INFO PDU is 
received, depending on the notification, the following actions are taken by CC: 

a) Call in queue 

When the SwMI has put a call into a queue it may send a D-INFO PDU. If the D-INFO PDU contains a value for the 
call time-out, set-up phase, the CC shall start timer T301 or T302, as appropriate, using the specified value. The CC 
shall send the information to the application in a TNCC-NOTIFY indication primitive. If the call is queued at call set-up 
time the D-INFO PDU should be preceded by a D-CALL PROCEEDING PDU. 

b) Call is proceeding 

This may be sent to the calling user application during the call set-up phase to indicate e.g. that the call set-up time 
through a gateway will be longer than for a normal call set-up time. The information that the timer value shall be 
changed is made available to the CC sub-entity in the D-INFO PDU. The CC shall start T302 with the indicated timer 
value. The CC shall send the information further on to the application in a TNCC-NOTIFY indication primitive. 

c) SwMI is paging called user 

When the SwMI is paging a called user, e.g. when the called user is on another network, the SwMI may send a D-INFO 
PDU with the call status parameter indicating this situation. If the D-INFO PDU contains a value for the call time-out, 
call set-up phase element, the CC shall start timer T302 using the specified value. 

d) Prolonging the call time-out time 

The SwMI may decide to change the call time-out time by sending a D-INFO PDU with a new T310 value. Upon 
reception of the D-INFO PDU containing the "call time-out" element, T310 shall be started using the defined value. If 
the SwMI supplies a T310 value in the D-INFO PDU, it shall set the value of the "reset call time-out timer" element of 
the PDU to indicate reset of T3 10. 

The SwMI may also choose to reset the call time-out time and start it again using the current defined value. Upon 
reception of the D-INFO PDU with the "reset call time-out timer" element indicating that T310 shall be reset, T3I0 
shall be started using the value defined earlier. 

In either case, the Timer value shall be sent further on to the application in a TNCC-NOTIFY indication primitive. 

The SwMI may also change the call timeout time during call restoration by supplying the "call time-out" element in the 
D-CALL RESTORE PDU, refer to clause 14.5.1.2.4. If the SwMI suppHes a T310 value in the D-CALL RESTORE 
PDU, it shall set the value of the "reset call time-out timer" element of the PDU to indicate reset of T310. 

NOTE 1: This procedure is applicable both in semi-duplex and full-duplex calls. 

e) Imminent call disconnection 

The SwMI may also inform MS that the call is about to end by sending D-INFO PDU with notification value "Notice of 
imminent call disconnection" shortly before the actual call disconnection. Upon reception of notification "Notice of 
imminent call disconnection" CC may send this notification to the application in a TNCC-NOTIFY indication primitive. 

NOTE 2: The time between notification and disconnection is outside the scope of the present document. 

Most downlink CC PDUs may contain a Notification indicator information element (in addition to the D-INFO PDU) 
and SwMI may inform calling/called user about offered or connected service using the Notification indicator 
information element. CC may send this notification to the application in corresponding TNCC service primitive. 
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14.5.1.2.3 Call modification procedures 



The MS service user may modify the service of an existing call. To initiate a modification the user application shall 
issue a TNCC -MODIFY request primitive and the CC sub-entity shall send a U-INFO PDU and wait for a D-INFO 
PDU from the SwMI before changing any of the current service parameters. The SwMI should not send D-INFO PDU 
to modify a service while an ongoing U-plane transmission is in progress. 

When a service has been changed by the SwMI, e.g. when a point-to-point call has been changed to 
a point-to-multipoint call, the SwMI should indicate this to the calling and called parties by sending a D INFO PDU. 
Upon reception of a D-INFO PDU the CC sub-entity shall send it to the application in a TNCC-MODIFY indication 
primitive. Finally the CC shall send a CONFIGURE request primitive for lower layer configuration. 

If the SwMI is unable to provide the requested service, it should either send a D-INFO PDU to the requesting party 
containing the current service (unchanged), or send a D-INFO PDU to the calling and called parties containing an 
alternative service. For example, if a user application requests an increase from a 1-slot per frame call to a 4-slots per 
frame call, and the SwMI is unable to allocate more than 2-slots to the call, it may offer a 2-slots per frame call in the 
D-INFO PDUs. 

If the call has changed from point-to-point to point-to-multipoint, a temporary group address and a group call reference 
number (call identifier) shall be given. The new group call reference number can be the current call identifier of the 
including party. 

The service may be changed between any combination of one or more of the following: 

duplex operation may be changed to simplex operation; or 

simplex operation may be changed to duplex operation; 

a point-to-point call may be changed to a point-to-multipoint call; 

a clear call may be changed to an encrypted call; or 

an encrypted call may be changed to a clear call; 

a 4-slots per frame call may be changed to a 1-slot, 2-slot or 3-slot call; 

a 3-slot call may be changed to a 1-slot, 2-slot or 4-slot call; 

a 2-slot call may be changed to a 1-slot, 3-slot or 4-slot call; 

a 1-slot call may be changed to a 2-slot, 3-slot or 4-slot call; 

a circuit mode type (TCH/S, TCH/7.2, TCH/4.8 or TCH/2.4) may be changed to a different circuit mode type 
(with the requested interleaving depth in the case of TCH/4.8 or TCH/2.4); 

a protected circuit mode data type (TCH/4.8 or TCH/2.4) may be changed to a different interleaving depth 
from the set of permissible values (N = 1, 4 or 8). 

NOTE: The clear and encrypted calls refer to the end-to-end clear and encrypted calls. The end-to-end encryption 
control is independent of the air interface encryption control. 

It is also possible to change between the circuit mode speech teleservices. 

The encryption state of each transmission, defined using D-TX GRANTED PDU, can be set independently by the 
encryption control element in the U-TX DEMAND PDU. The SwMI should not change the requested encryption state 
in the responding D-TX GRANTED PDU from that requested in the U-TX DEMAND PDU. 

If the MS cannot support a new service combination, indicated by D-INFO, D-TX GRANTED or D-TX INTERRUPT 
PDU, the user application or the CC, as appropriate, shall disconnect the call (see clause 14.5.1.3.1). The 
U-DISCONNECT PDU shall contain disconnection cause "requested service not available" or in case of incompatible 
encryption control, the disconnect cause shall be "Called party does not support encryption" or "Called party requires 
encryption". 
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14.5.1.2.4 



Call restoration procedures 
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Figure 14.13: Individual call - successful call restoration 
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Figure 14.14: Individual call - unsuccessful call restoration 

The responsibility of the procedure shall be to restore the call when the temporary break condition has been resolved by 
lower layers. 

When the CC receives a BREAK indication primitive, then the CC sub-entity shall try to restore the call as described in 
this clause: 

• when the CC receives a BREAK indication primitive, the CC shall send a CONFIGURE request primitive to 
switch the U-plane off as described in clause 14.5. 1 .4 and remain in state CALL- ACTIVE. If the CC had 
permission to transmit/send data at that time the CC shall assume that the permission is now ended as if the CC 
had sent a U-TX CEASED PDU or SwMI had withdrawn permission to talk. If the MS is in state WAIT when 
it receives a BREAK indication primitive then it shall behave as if it had received a D-TX CONTINUE PDU 
with the continue element set to "not continue". It shall then obey the instructions in the D-CALL RESTORE 
PDU; 
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if the CC receives a RESUME indication primitive indicating that the C-plane may now be used again, it shall 
issue a U-CALL RESTORE PDU in a RESTORE request primitive containing the SSI, TSI or SNA of the 
other party in the individual call and the call identifier of the call which CC wants to restore. If the other party 
address is not available, then the dummy address (all zeroes) shall be used. If the CC wishes to continue 
transmission in the new cell, or keep a queued transmission request valid in the new cell, it shall indicate so in 
the request to transmit/send data information element in the U-CALL RESTORE PDU. A MS which has 
requested for transmit permission on a previous cell and has received a "transmission request queued" response 
or no response at all on that cell, may either refresh the transmission request by requesting for transmit 
permission in the U-CALL RESTORE PDU on the new cell, or withdraw the transmission request by 
requesting for receive permission in the U-CALL RESTORE PDU on the new cell. A MS which attempts call 
restoration having received a "transmission request queued" indication on a previous cell can assume that its 
transmission request is still held in the SwMI's queue unless the MS receives a "transmission not granted" 
indication within the call restoration signalling. After sending a U-CALL RESTORE PDU, CC shall start 
timer T306 and wait for a D-CALL RESTORE PDU; 

when the CC receives a D-CALL RESTORE PDU in a RESTORE indication primitive, timer T306 shall be 
stopped, and the call shall be resumed with the new parameters, see figure 14.13. The CC shall obey the 
transmission granting in the transmission grant information element for both semi -duplex and full-duplex calls, 
refer to clause 14.5.1.2.1. Timer T310 shall be reset and started only if the "Reset call timeout" information 
element value is 1 (Reset call time-out timer T310); the T310 value shall be taken from the 
D-CALL RESTORE PDU call timeout information element and, if not present in the PDU, from the previous 
value (provided in D-CONNECT, D-CONNECT ACKNOWLEDGE or D-INFO PDU). If appropriate the CC 
shall issue a CONFIGURE request primitive using the procedure in clause 14.5.1.4; 

if a MS restores to a cell without requesting for transmit permission and receives a D-CALL RESTORE PDU 
with "Call status" element having value "Call is queued" (indicating that the cell has no available traffic 
resources), the value of the "Transmission grant" element in the D-CALL RESTORE PDU shall be 
"Transmission not granted". If the call subsequently proceeds to traffic (it may be cleared while queued), the 
MS shall expect to receive one of the following PDUs; the MS shall then expect no further signalling for the 
call restoration: 

simplex call: D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission grant" 
element having value "Transmission granted to another user". The MS shall switch the U-plane on; the 
MS is authorized to receive traffic; 

simplex call: D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission grant" 
element having value "Transmission not granted". The MS shall retain its current U-plane state (and shall 
perform the channel change); 

duplex call: not applicable - the MS shall request for permission to transmit when restoring to a duplex 
call; 

if a MS restores to a cell, requests for transmit permission, and receives a D-CALL RESTORE PDU with 
"Call status" element having value "Call is queued" (indicating that the cell has no available traffic resources), 
the value of the "Transmission grant" element in the D-CALL RESTORE PDU shall be either "Transmission 
request queued" (MS shall wait for further signalling to indicate the result of its request to transmit) or 
"Transmission not granted" (MS's request to transmit is rejected - this is not a valid response for a duplex call; 
MS behaviour if it receives such a response is outside the scope of the present document). If the call 
subsequently proceeds to traffic (it may be cleared while queued), the MS shall expect to receive one of the 
following PDUs: 

simplex call: D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission grant" 
element having value "Transmission granted to another user". The MS shall switch the U-plane on; the 
MS is authorized to receive traffic; the MS shall, if its request to transmit was not rejected by the "Call is 
queued" D-CALL RESTORE PDU, wait for further signalling to indicate the result of its request to 
transmit; 

simplex call: D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission grant" 
element having value "Transmission not granted". The MS shall retain its current U-plane state (and shall 
perform the channel change); the MS's request to transmit, if still outstanding following receipt of the 
"Call is queued" D-CALL RESTORE PDU, is rejected; 
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simplex call: D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission grant" 
element having value "Transmission request queued". The MS shall not switch the U-plane on (but shall 
perform the channel change); the MS shall wait for further signalling to indicate the result of its request 
to transmit. The SwMI shall not use this value of the "Transmission grant" element if the "Call is 
queued" D-CALL RESTORE PDU rejected the MS's request to transmit; MS behaviour if it receives 
such a response in this context is outside the scope of the present document; 

simplex call: D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission grant" 
element having value "Transmission granted". The MS shall switch the U-plane on; the MS is authorized 
to transmit. The SwMI shall not use this value of the "Transmission grant" element if the "Call is 
queued" D-CALL RESTORE PDU rejected the MS's request to transmit; MS behaviour if it receives 
such a response is described in clause 14.5.1.2.1 b) (refer to text describing handling of unsolicited 
transmission grant); 

duplex call: D-TX GRANTED PDU, containing a channel allocation, with "Transmission grant" element 
having value "Transmission granted". The MS shall switch the U-plane on; the MS is authorized to 
transmit and receive. 

On expiry of Timer T306, the procedure defined in clause 14.5.1.3.4 shall apply. 

The call length timer T310 shall continue running during the call restoration and on expiry of T310, the procedure 
defined in clause 14.5.1.3.4 shall apply. 

If the call cannot be resumed the CC should receive a REOPEN indication primitive indicating that the call is lost. The 
CC shall then stop Timer T306 and return to state IDLE, and it shall send a TNCC-RELEASE indication primitive to 
the user application with the cause of disconnection, see figure 14.14. 

If the SwMI provides a new call identifier with the D-CALL RESTORE PDU, CC shall use it in all subsequent 
signalling relating to that call. After a cell change, the MS shall not send any other call related signalling than 
U-CALL RESTORE PDU until it has received a D-CALL RESTORE PDU (and possible new call identifier) from the 
SwMI. 

A MS which is queueing for a traffic channel during restoration and which has an outstanding transmission request, 
may cancel that transmission request by sending a U-TX CEASED PDU. A MS which is queueing for a traffic channel 
during restoration and which does not have an outstanding transmission request, may make a transmission request by 
sending a U-TX DEMAND PDU, providing the SwMI has not disallowed transmission requests (via the "transmission 
request permission" element). 

If there is more than one circuit mode call active at the time when the MLE-BREAK indication primitive was received, 
each call shall be restored separately and hence U-CALL RESTORE and D-CALL RESTORE PDUs shall be 
exchanged one by one for each call. 

14.5.1.2.5 DTMF procedures 

When a user application requires to transfer DTMF digits to another user application during a circuit mode call, it shall 
issue a TNCC-DTMF request primitive (DTMF tone delimiter = "DTMF tone start") to the CC entity, followed by a 
TNCC-DTMF request primitive (DTMF tone deUmiter = "DTMF tone end") to the CC entity. The duration of time 
between the "start" and "end" primitives, and the number of digits contained in the start primitive, shall be 
application-dependent, though normally generation of the start primitive will correspond with a DTMF key press, 
generation of the end primitive will correspond with the release of that key and the start primitive will contain the digit 
corresponding to the key press. 

CC shall generate U-INFO PDUs corresponding to the TNCC-DTMF request primitives (see clauses 14.8.19, 14.8.19a 
and 14.8.19b), the only restriction being that CC shall not send a "DTMF tone end" U-INFO PDU if layer 2 has not 
indicated successful transmission of the preceding "DTMF tone start" U-INFO PDU. 

On the reception of a D-INFO "DTMF tone start" PDU the CC shall forward the DTMF digits contained in the PDU to 
the user application in a "start" TNCC-DTMF indication primitive. On the reception of a D-INFO "DTMF tone end" 
PDU the CC shall send an "end" TNCC-DTMF indication primitive to the user application. If CC receives two identical 
"start" PDUs (i.e. containing the same DTMF digits) without an intervening "end" PDU it shall ignore the second "start" 
PDU. If CC receives two "end" PDUs without an intervening "start" PDU it shall ignore the second "end" PDU. If CC 
receives two different "start" PDUs without an intervening "end" PDU it shall forward the digits contained in both 
PDUs to the user application. 
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A SwMI may choose to filter repeated "start" and "end" DTMF U-INFO PDUs in the manner described in the previous 
clause before forwarding DTMF digits to a MS (in a D-INFO PDU) or gateway (see below). 

A receiving MS or gateway which does not support or subscribe to DTMF signalling may respond to a DTMF D-INFO 
PDU with a U-INFO PDU, the DTMF type element (refer clause 14.8.19b) having value "DTMF not supported" or 
"DTMF not subscribed". The SwMI should forward this response to the addressed MS (i.e. the MS which initiated the 
DTMF signalling) in a D-INFO PDU. 

A receiving SwMI which does not support or subscribe to DTMF signalling may respond to a DTMF U-INFO PDU 
with a D-INFO PDU, the DTMF type element (refer clause 14.8.19b) having value "DTMF not supported" or "DTMF 
not subscribed". 

On the reception of a D-INFO "DTMF not supported" or "DTMF not subscribed" PDU (refer clause 14.8.19b), CC shall 
forward the failure to the user application in a TNCC-DTMF indication primitive containing a "DTMF result" 
parameter specifying the nature of the failure (refer clause 1 1.3.3.3). Note that a user application should receive such an 
indication only after having generated DTMF digits itself It is outside the scope of the present document how the user 
application should handle the rejection of DTMF signalling. 

The U-INFO PDU may be routed to a gateway. In this case, the receiving user application can be for example, either an 
external network subscriber application or an exchange of the external network that uses two stage dialling to set-up 
calls in the external network. The gateway shall convert the DTMF digits into dual tone multi-frequency signals 
towards the external network. The gateway shall support the filtering of repeated "start" and "end" DTMF U-INFO 
PDUs described above. 

A receiving entity (i.e. MS or gateway) shall start generation of one or more DTMF tones at the first reception of a 
"start" PDU. The receiving entity shall ignore any repeated "start" PDUs. It is outside the scope of the present document 
how DTMF tones are generated if the receiving entity receives two or more different "start" PDUs without an 
intervening "end" PDU. 

The "end" PDU shall stop the generation of tone or tones after the minimum period of tone/no-tone sequence or 
sequences as defined for the application e.g. PSTN gateway. When the reception of the "end" PDU is delayed longer 
than the minimum tone period of the single or last digit in the "start" PDU the tone generating application may continue 
to generate tone for a predefined time; the generation time is outside the scope of the present document. The receiving 
entity shall ignore any repeated "end" PDUs. 

The next "start" PDU after an "end" PDU shall start generation of the DTMF tone only after a valid no-tone period as 
defined for the application. 

The minimum length of tone generated by the tone generating application, e.g. a gateway, should be suitable for 
potential applications in analog telecommunication networks. 

NOTE 1: The DTMF signalling can be used only after either a D-CONNECT or D-CONNECT ACK PDU has been 
received and the TETRA call is established. 

NOTE 2: DTMF signalling may not function correctly during a circuit mode data call (a data modem signal will 
seriously disturb and be disturbed by DTMF signalling). The support of DTMF signalling during data 
calls is outside the scope of the present document. 

14.5.1.2.6 Calls to and from external subscribers 

An MS can make a call to a subscriber in an external network using a gateway. The call set-up message shall address 
the gateway using a particular SSI as the called party address and the U-SETUP PDU shall contain the external network 
subscriber number in the corresponding element. The gateway shall then set-up the call to the external network 
subscriber using that number without further call set-up messages from the calling MS. 

NOTE 1: The particular SSI address or addresses which identify the gateway or gateways are not defined by this 
part of the present document. 

NOTE 2: Calls from external network subscribers to TETRA subscribers are supported in the air interface including 
presentation of the external user number, if available. This part of the present document does not describe 
gateway functions, which are independent of the air interface protocol. 
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14.5.1 .3 Call disconnection procedures 
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NOTE: For the purposes of clarity, only 1 instance of mle_report has been shown. 
Figure 14.15: Individual call request-to-disconnect 



14.5.1.3.1 



User initiated disconnection 



Either the calling or called user application may initiate a call disconnection at any state of a call. This shall be done by 
sending a TNCC-RELEASE request primitive to the CC sub-entity. 

• During call set-up phase until the U-SETUP PDU has been transmitted to the SwMI, a disconnection can be 
handled locally using a CANCEL request primitive. Information regarding the local progress of the 
transmission of a PDU is received in REPORT indication primitives. After a local cancellation the CC sub- 
entity shall stop timer T303 and return to state IDLE. 

• On receipt of a TNCC-RELEASE request primitive the CC sub-entity shall enter state CALL-DISCONNECT, 
send a U-DISCONNECT PDU, start timer T308 and stop all other T3xx timers. The progress of the 
disconnection PDU sending shall be reported back to CC with REPORT indication primitives. 

• Should the user application disconnect the call during the window between transmission of a U-SETUP and 
reception of a D-CALL PROCEEDING, D-ALERT or D-CONNECT PDU (i.e. before the MS has received a 
call identifier for the call), it shall use the dummy call identifier (all zeroes). 

• After sending a U-DISCONNECT PDU the CC shall wait for a D-RELEASE PDU. When a D-RELEASE 
PDU or a REPORT indication primitive with reason PDU transfer failed is received, or timer T308 expires, the 
CC sub-entity shall clear the call identifier and shall return to state IDLE, issuing a TNCC-RELEASE confirm 
primitive to the user application, see figure 14.15. The CC sub-entity shall send a CONFIGURE request 
primitive to the lower layers to switch the U-Plane off, reject any pending channel change response request for 
that call (refer to clause 14.5.3.2), and leave the assigned channel (if the MS is on an assigned channel when 
the CONFIGURE request primitive is sent). If a channel change response is required for the D-RELEASE 
PDU, CC shall accept that channel change (refer to clause 14.5.3.2). 
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The SwMI should inform the other MS in the call of the call clearance either by a D-DISCONNECT PDU or by 
a D-RELEASE PDU, see clause 14.5.1.3.3. 

14.5.1.3.2 Network initiated disconnection 

In the case where the SwMI cannot support a request for a call from the calling MS, the SwMI should send 
a D-RELEASE PDU, containing the reason for disconnection, to the calling MS. 

In the case where the SwMI can no longer support an established call, it should send D RELEASE PDUs to the calling 
and called MSs containing the reason for disconnection, and should subsequently release the call. 

Refer to clause 14.5.1.3.3 for the MS actions. 

14.5.1.3.3 Reception of disconnection request 

The BS may send a disconnection request at any phase of the call and the MS shall react as follows: 

• when the CC sub-entity receives a D-DISCONNECT PDU the CC shall respond by sending a U-RELEASE 
PDU; 

• when the CC sub-entity receives a D-RELEASE PDU the CC shall not send any response; 

• in both cases the CC shall inform the user application with a TNCC-RELEASE indication primitive, clear the 
call identifier, stop all T3xx timers and enter state IDLE, see figure 14.15. The CC sub-entity shall send 

a CONFIGURE request primitive informing the lower layers to switch the U-Plane off, reject any pending 
channel change response request for that call (refer to clause 14.5.3.2), and leave the assigned channel (if the 
MS is on an assigned channel when the CONFIGURE request primitive is sent). If a channel change response 
is required for the D-RELEASE PDU or D-DISCONNECT PDU, CC shall accept that channel change (refer 
to clause 14.5.3.2). 

14.5.1.3.4 Expiry of timers 

a) Timer T301 ; call set-up timer for called MS 

Upon expiry of timer T301, CC shall send a TNCC-RELEASE indication primitive to the user application, send 
a U-DISCONNECT PDU and follow the procedures in clause 14.5.1.3.1. The value of the disconnect cause element 
shall be set to "expiry of timer". 

b) Timer T302; call set-up timer for calling MS 

Upon expiry of timer T302, CC shall send a TNCC-RELEASE indication primitive to the user application, send 
a U-DISCONNECT PDU and follow the procedures in clause 14.5.1.3.1. The value of the disconnect cause element 
shall be set to "expiry of timer". 

c) Timer T303; call initiated timer for calling MS 

Upon expiry of timer T303, CC shall send a TNCC-RELEASE indication primitive to the user application, send 

a U-DISCONNECT PDU and follow the procedures in clause 14.5.1.3.1. The value of the Disconnect Cause element 

shall be set to "expiry of timer". 

d) Timer T306; call restoration timer for point-to-point calls 

Upon expiry of timer T306, CC shall return to state IDLE, and send a TNCC-RELEASE indication primitive to the user 
application. The value of the disconnect cause element shall be set to "expiry of timer". 
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e) Timer T308; call disconnect timer 



Upon expiry of timer T308, CC shall return to state IDLE, send a TNCC-RELEASE confirm primitive to the user 
application and shall send a CANCEL request primitive to the lower layers to cancel the sending of the 
U-DISCONNECT PDU. The CC sub-entity shall send a CONFIGURE request primitive to the lower layer to switch the 
U-Plane off, reject any pending channel change response request for that call (refer to clause 14.5.3.2), and leave the 
assigned channel (if the MS is on an assigned channel when the CONFIGURE request primitive is sent). 

f) Timer T31 0; call length timer 

Upon expiry of timer T310, CC shall send a TNCC-RELEASE indication primitive to the user application, send 
a U-DISCONNECT PDU and follow the procedures in clause 14.5.1.3.1. The value of the disconnect cause element 
shall be set to "expiry of timer". 

g) Timer T31 1 ; call transmission timer 
Refer to 14.5.1.2.1 g). 

14.5.1.3.5 Colliding disconnection 

Disconnection collision can occur when both sides simultaneously send DISCONNECT PDUs specifying the same call 
identifier value. If a CC sub-entity receives a D-DISCONNECT PDU when CC has just issued a U-DISCONNECT 
PDU, the CC sub-entity shall discard the outgoing disconnection request and respond to the incoming 
D-DISCONNECT PDU as defined in clause 14.5.1.3.3. 

If the U-DISCONNECT PDU colUdes with a D-RELEASE PDU, the CC sub-entity shall release the call immediately 
as defined in clause 14.5.1.3.3. 

In either case the CC shall send a CANCEL request primitive to the lower layers to cancel the sending of the 
U-DISCONNECT PDU. 

1 4.5.1 .4 U-Plane switching 

The U-Plane switching procedure ensures that traffic/signalling synchronization between CMCE and MAC is 
maintained during the lifetime of a call. The CC informs the MAC when it has permission to transmit traffic (i.e. TCH 
or STCH) and when to stop. The CC also informs the MAC when it may process received traffic (and when to stop). 
The latter procedure also assists the MAC to interpret when the received bit-stream on the assigned channel is 
TCH/STCH and when it is SCH. 

The CC changes the U-plane operation in the MAC by issuing the CONFIGURE request primitive, indicating "Switch 
U-plane = On" or "Switch U-plane = Off, "Tx grant = true" or "Tx grant = false" and "simplex/duplex = simplex" or 
"simplex/duplex = duplex". There shall be only four valid combinations: 

1) Switch U-plane = On, Tx grant = true, simplex/duplex = simplex: 

MS is authorized to transmit traffic. 

2) Switch U-plane = On, Tx grant = false, simplex/duplex = simplex: 

MS is authorized to receive traffic. 

3) Switch U-plane = On, Tx grant = true, simplex/duplex = duplex: 

MS is authorized to transmit and receive traffic. 

4) Switch U-plane = Off: 

withdraws previous authorization to transmit and/or receive traffic. 
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14.5.1.4.1 End of call set-up phase 



When the CC in a MO call receives a D-CONNECT PDU, or when the CC in a MT call receives a D-CONNECT 
ACKNOWLEDGE PDU, it shall issue a CONFIGURE request primitive to the lower layers containing information 
about the call e.g. the type of traffic, the interleaving depth, the call identifier and whether the call is end-to-end 
encrypted. 

If the transmission grant element in the PDU is set to "transmission granted" then the CONFIGURE request primitive 
shall contain the parameter value "Switch U-Plane = On" and "Tx grant = true" to indicate that the MAC has permission 
to transmit traffic. If the transmission grant element is set to "transmission granted to another user" then the 
CONFIGURE request primitive shall contain the parameter value "Switch U-Plane = On" but shall contain "Tx grant = 
false" to indicate that the MAC should receive traffic. 

For the other values of the transmission grant element, the U-plane shall not be switched on. 

14.5.1 .4.2 During call maintenance phase 

a) Transmission grant control 

When the CC receives a D-TX GRANTED PDU, and if the transmission grant element is set to "transmission granted" 
or "transmission granted to another user", then the CC shall issue a CONFIGURE request primitive containing the 
parameter value "Switch U-Plane = On" and indicating whether the MAC has permission to transmit traffic 
("Tx grant = true" or "Tx grant = false" respectively). For the other values of the transmission grant element, the 
U-plane state shall not be changed. 

NOTE: Sometimes consecutive CONFIGURE request primitives issued to the lower layers will both contain the 
instruction to "Switch U-plane On" but will change the traffic transmit permission. 

b) Transmission ceased 

When CC receives a D-TX CEASED PDU, or on receipt of a REPORT indication primitive of either successful or 
unsuccessful transmission of a U-TX CEASED PDU, the CC shall issue a CONFIGURE request primitive containing 
the parameter value "Switch U-Plane = Off. 

c) Temporary pause 

When the CC receives a D-TX WAIT PDU, and if the U-plane is currently switched on for either transmission or 
reception, the CC shall issue a CONFIGURE request primitive containing the parameter value "Switch U-plane = Off. 

When the CC receives a D-TX CONTINUE PDU, and if the Continue element is set to "continue" and the U-plane was 
switched on at the time of receipt of the D-TX WAIT PDU, then the CC shall issue a CONFIGURE request primitive 
containing the same parameter values as before the temporary interruption. Otherwise, the U-plane shall not be 
switched on. 

d) Interruption 

When the CC receives a D-TX INTERRUPT PDU, and if the transmission grant element is set to "transmission granted 
to another user", the CC shall issue a CONFIGURE request primitive containing the parameter value "Switch U-Plane = 
On" but shall contain "Tx grant = false" to indicate that the MAC should receive traffic (and no longer has permission to 
transmit traffic). For the other values of the transmission grant element, the CC shall issue a CONFIGURE request 
primitive containing the parameter value "Switch U-Plane = Off. 

e) Call restoration 

When CC receives a BREAK indication primitive indicating that a temporary break in the radio link has occurred, the 
CC shall issue a CONFIGURE request primitive containing the parameter value "Switch U-Plane = Off". 

When CC receives a D-CALL RESTORE PDU indicating that the call has now been restored after a temporary break in 
the radio link, and if the transmission grant element is set to "transmission granted" or "transmission granted to another 
user", then the CC shall issue a CONFIGURE request primitive containing the parameter value "Switch U-Plane = On" 
and indicating whether the MS has permission to transmit traffic ("Tx grant = true" or "Tx grant = false" respectively). 
For the other values of the transmission grant element, the U-plane shall not be switched on. 
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14.5.1.4.3 



Call disconnection phase 



When CC receives a D-RELEASE PDU or a D-DISCONNECT PDU, or on receipt of a REPORT indication primitive 
of either successful or unsuccessful transmission of a U-DISCONNECT PDU, the CC shall issue a CONFIGURE 
request primitive to the lower layers containing the parameter value "Switch U-Plane = Off". 

14.5.2 Group CC procedures 

The CC procedures handled by CC shall be applicable for circuit mode calls for both speech and data. The circuit mode 
speech and data group calls shall be set-up as point-to-multipoint calls. The specification below shall be applicable for 
the procedures that reside in the MS. 

14.5.2.1 Call set-up procedures 



a) Normal group call 

The normal group call procedures provide support for one type of call set-up, where the MS is placed immediately into 
the call upon receipt of the D-SETUP PDU if the called user application can support the call and with immediate action 
being taken by the called user application, refer to figure 14.16. 

The set-up signalling procedures shall allow immediate communication to take place between the calling and called 
user applications without the possibility of having an alerting process and without an explicit response from the called 
user application stating that the user has answered. The call priority may affect whether the user application accepts the 
call or not. 

NOTE: The behaviour of the user application between the reception of the incoming set-up signalling and the 
acceptance/reject of the call is outside the scope of the present document. 

The MS does not signal that acceptance or rejection to the BS. 
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Figure 14.16: Group call - set-up phase 
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b) Acknowledged group call 

An acknowledged group call allows the SwMI to poll members of the called group during the call. The call may be 
through connected to the calling MS either before polling or after polling has taken place (see clause 14.5.2.6), refer to 
figure 14.17. 
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Figure 14.17: Acknowledged group call - set-up phase 



c) Broadcast call 



The call set-up procedure for broadcast call shall be the same as that for group call as shown in figure 14. 16. However, 
in this case the called MSs shall not be allowed to subsequently request transmit permission. 



14.5.2.1.1 



Incoming call 



Notification of the arrival of an incoming call to the CC sub-entity shall be made by the reception of a D-SETUP PDU 
which shall be delivered to the user application in a TNCC-SETUP indication primitive via the TNCC-SAP. The CC 
shall enter state MT-CALL-SETUP. If the user application can support the call, it shall immediately return 
a TNCC-SETUP response primitive. 

On reception of a TNCC-SETUP response primitive the CC sub-entity shall enter state CALL ACTIVE and take the 
following actions, which are dependent upon the information contained within the PDU elements, see figure 14.16, 
right hand side: 

• the call identifier shall be used as the reference to this call in subsequent PDUs for the duration of the call; 

• when CC receives TNCC-SETUP response primitive indicating that the called user application has accepted 
the incoming call, the CC sub-entity shall enter state CALL ACTIVE and start timer T310. The D-SETUP 
PDU shall contain an indication in the transmission grant element whether the MS should switch to U-plane 
reception. If the D-SETUP PDU contains an indication that the MS is allowed to request transmission 
permission it may follow the transmission control procedures described in clause 14.5.2.2.1 a). The CC 
sub-entity shall send a CONFIGURE request primitive for lower layer configuration accepting the channel 
change; 
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• where the called user application is unable to accept the request for a certain target service, the call shall be 
rejected locally by issuing a TNCC-RELEASE request primitive via the TNCC-SAP and the CC shall enter 
state IDLE. No negotiation with the BS shall be possible. The CC sub-entity shall send a CONFIGURE 
request primitive for lower layer configuration rejecting the channel change. 

14.5.2.1.2 Outgoing call 

A user application initiates call establishment by transferring a TNCC-SETUP request primitive across the TNCC-SAP 
to the CC sub-entity. The TNCC-SETUP request primitive shall be handled by a CC sub-entity that is in state IDLE. 
The CC shall select a PDU priority based on the requested access priority value as defined in clause 14.5.6.2. The CC 
shall convert this request into a U-SETUP PDU and send it. The CC sub-entity shall then enter the MO-CALL-SETUP 
state and start timer T303, see figure 14. 16 - left hand side. 

The following text describes the normal call set-up procedures: 

• to indicate the progress of the transmission of the U-SETUP PDU the CC may receive one or more REPORT 
indication primitives. If the CC receives a REPORT indication primitive informing that the PDU transmission 
has failed, timer T303 shall be stopped, and the CC sub-entity shall inform the user application with 

a TNCC-RELEASE indication primitive and return to state IDLE; 

• the SwMI may respond to the reception of the U-SETUP PDU with a D-CALL PROCEEDING PDU. Upon 
reception of the D-CALL PROCEEDING PDU, the CC shall inform the user application by issuing 

a TNCC -PROCEED indication primitive, stop timer T303, and start timer T302; 

• the D-CALL PROCEEDING PDU shall contain a call identifier which shall be used as the reference to this 
call in subsequent PDUs for the duration of the call; 

• the D-INFO PDU shall not be used to allocate a call identifier; 

• on reception of a D-INFO PDU after reception of D-CALL PROCEEDING PDU but before the call set-up is 
completed, the CC shall start timer T302 from the value indicated in the call time out, set-up phase element if 
that element is present; 

• if the call through connection is ready at the time when the D-CALL PROCEEDING PDU should have been 
sent, a D-CONNECT PDU should be sent instead. In this instance the D-CONNECT PDU shall allocate the 
call identifier; 

• on receipt of a D-CONNECT PDU, the CC shall enter state CALL- ACTIVE, and inform the user application 
with a TNCC-SETUP confirm primitive, and stop timer T302 or T303 and start timer T310. The 
D-CONNECT PDU shall contain an indication as to whether the CC has been given permission to transmit. If 
transmission is not granted and the D-CONNECT PDU contains an indication that the MS is allowed to 
request transmission permission it may follow the transmission control procedures defined in clause 14.5.2.2.1. 
The CC sub-entity shall send a CONFIGURE request primitive for lower layer configuration accepting the 
channel change. If the CC has been given permission to transmit then it shall start timer T3 11 ; 

• where the D-CONNECT or D-CALL PROCEEDING PDU indicates that the offered service is different to the 
one requested, and if the service offered is acceptable to the CC sub-entity according to the selected lowest 
service in the TNCC-SETUP request primitive, then the call shall continue. If it is not acceptable, then the CC 
shall disconnect the call using the procedures in clause 14.5.2.3.1; 

• the network may support other signalling from the calling MS to the SwMI and vice versa during the call 
set-up phase using U-INFO and D-INFO PDUs, for example, for the purpose of showing the progress of a call 
set-up. 
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• on reception of a group addressed D-SETUP PDU after reception of D-CALL PROCEEDING PDU (and 
optionally D-INFO PDU), if the call identifier in the D-SETUP is the same as the call identifier in the 
D-CALL PROCEEDING PDU and the calling party address in the D-SETUP PDU does not contain the MS's 
own address, the CC sub-entity shall enter state CALL ACTIVE, stop timer T302 and start timer T310. The 
D-SETUP PDU shall contain an indication in the transmission grant element whether the MS should switch to 
U-plane reception. If the D-SETUP PDU contains an indication that the MS is allowed to request transmission 
permission it may follow the transmission control procedures described in clause 14.5.2.2.1 a). The CC 
sub-entity shall send a CONFIGURE request primitive for lower layer configuration accepting the channel 
change. CC shall ignore the D-SETUP PDU if the calling party address is the same as the MS's own address 
and shall send a CONFIGURE request primitive for lower layer configuration ignoring the channel change. A 
MS following a group addressed D-SETUP in the manner described in this clause shall cancel its request to 
transmit if it requested to transmit in the U-SETUP PDU. 

NOTE 1: The SwMI should either send the D-CONNECT PDU granting transmit permission first or supply the 
calling party address in the D-SETUP PDU (or both) to prevent the MS that is about to be granted 
transmit permission following the group addressed D-SETUP PDU. 

NOTE 2: Handling of the TNCC-SETUP request primitive may be affected by the MS being active in a MM 
procedure, this being indicated to CC from MLE via the MLE-BUSY indication primitive, refer to 
clause 18.3.5.4. The exact nature of the interaction between MM/MLE and CC is outside the scope of this 
part of the present document but it is recommended that CC not accept a TNCC-SETUP request primitive 
while MM is busy. 

14.5.2.1.3 Colliding calls 

Call collisions can occur when both the SwMI and the MS simultaneously send a D-SETUP PDU and a U-SETUP 
PDU. Two call set-ups are colliding when a D-SETUP PDU is received within the window where the CC waits for a 
call identifier from the SwMI after a U-SETUP PDU has been issued. The MS shall be able to handle two types of call 
collision: 

• if the colliding calls are call set-up attempts for the same group and the requested basic services are compatible 
and the calling MS is a member of that group and layer 2 has not indicated successful transmission of the 
U-SETUP PDU, then the MS CC shall attempt to discard the outgoing call set-up attempt by sending a 
CANCEL request primitive to the lower layers to cancel sending of the U-SETUP PDU. If cancellation is 
successful, the MS shall accept the incoming call. If cancellation is unsuccessful or if layer 2 has indicated 
successful transmission of the U-SETUP PDU, the MS shall continue its own call set-up and wait for 

a D-CALL PROCEEDING and/or D-CONNECT PDU (and/or D-RELEASE PDU); 

• if the call set-up attempts are not to the same group, then the MS shall either keep its call attempt or accept the 
incoming call as defined in clause 14.5.2.1.1. In the latter case the MS shall first cancel its call set-up locally, 
if still possible, or otherwise send a U-DISCONNECT PDU for its own call set-up, refer clause 14.5.2.3.1. If 
MAC requested a response with the parameter channel change response required value set to "true" with the 
CC message the CC shall select the proper radio resource by issuing MLE-CONFIGURE request primitive 
with value "reject" in the first case or "accept" in the latter case. Refer to clause 14.5.3.2. 

1 4.5.2. 1 .4 Unsuccessful call set-up 

Unsuccessful call set-up shall refer specifically to those instances where a circuit mode connection was not successfully 
established. It shall not refer to call disconnection or call rejection. If a PDU is not responded to prior to the expiry of 
the corresponding timer, the procedure in clause 14.5.2.3.5 shall apply. All timers available are listed in clause 14.6. 

When CC receives a REPORT indication primitive indicating that the lower layers have not been successful (failed 
transfer) in the sending of any of the call set-up PDUs, then the CC sub-entity shall return to state IDLE and inform the 
user application with a TNCC-RELEASE indication primitive accompanied with a cause of the disconnection. 

14.5.2.1.5 Call rejection 

If the user application decides to reject the incoming call set-up request as defined in clause 14.5.2.1.1, it shall 
immediately transfer a TNCC-RELEASE request primitive to the CC sub-entity. This request shall locally clear the call 
identifier. The CC sub-entity shall then change to state IDLE. 
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14.5.2.2 Call maintenance procedures 

The call maintenance procedures described in this clause may be applied when the MS is in states MO-CALL SETUP, 
MT-CALL SETUP or CALL-ACTIVE. The main state CALL-ACTIVE can comprise several sub-states. 

NOTE: The D-INFO PDU can be used for other purposes than those defined in the protocol specifications 
contained in the present document. 
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NOTE 1 : D-TX INTERRUPT PDU is sent to the remaining members of the group upon permission award to the MS 

shown on the left hand side of this figure. 
NOTE 2: For the purposes of clarity, instances of mle_report are not shown. 



Figure 14.18: Group call - request-to-transmit 



a) Request-to-transmit 



The SwMI shall fully control which MS is allowed to transmit. To faciUtate this, the MS shall request permission to 
transmit, and permission shall be granted before the MS can begin circuit mode traffic permission. MSs may request 
permission to transmit, if the SwMI allows it by a "transmission request permission" element even if another party is 
transmitting. In this case the SwMI should normally wait for that party to finish the transmission before granting the 
other user application. Pre-emptive priority requests are dealt with in clause 14.5.2.2.1 f). 

The SwMI normally gives the first permission to transmit to the calling MS when a new call has been set-up. However, 
the calling user application may allow the called users to request permission to transmit first. The calling CC shall in 
that case set the "request to transmit" bit accordingly in the U-SETUP PDU. 
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When a user within a call wants to transmit, a TNCC-TX request primitive shall be sent to CC via the TNCC-SAP. The 
CC shall send this request in a U-TX DEMAND PDU. The TX-DEMAND Priority level should be set to low or high 
priority, unless this is a pre-emptive priority request, see clause 14.5.2.2.1 f), see figure 14.18. 

The progress of the transmission of the U-TX DEMAND PDU shall be given locally to the CC in one or more REPORT 
indication primitives. If the CC receives a REPORT indication primitive as a response to the sending of the 
U-TX DEMAND PDU informing that the PDU transmission has failed, the CC shall inform the user application by a 
TNCC-TX confirm primitive. 

If a user application wants to withdraw his request-to-transmit before it has been granted, a TNCC-TX request primitive 
shall be sent from the user application to the TNCC-SAP. The CC shall send this request in a U-TX CEASED PDU. 
The CC shall send the U-TX CEASED PDU with the stealing permission set to "immediate stealing" and stealing 
repeats flag set so that the permission to transmit will be released immediately if allocated. No CC protocol response 
shall be received from the SwMI for this message. 

b) Response to request-to-transmit 

During a call in progress and when the SwMI has decided which MS shall be given permission to transmit, the SwMI 

shall send a D-TX GRANTED PDU as an individual message to the granted MS. Upon reception of 

a D-TX GRANTED PDU indicating "transmission granted", the CC sub-entity shall send this information to the user 

application in a TNCC-TX confirm primitive. The other MSs involved in the call shall be informed with 

a D-TX GRANTED PDU addressed with the group address. That D-TX GRANTED PDU shall indicate that permission 

to transmit has been granted to another user. The CC shall send this information to the user application in a 

TNCC-TX indication primitive and shall remain in state CALL- ACTIVE, see figure 14.18. 

If the SwMI places the transmission request in a queue this shall be indicated to the MS concerned using the 
"transmission request queued" parameter value in the D-TX GRANTED PDU. If the SwMI rejects the transmission 
request this may be indicated to the MS concerned using the "transmission not granted" parameter value in the 
D-TX GRANTED PDU. In either case, the MSs concerned shall remain in state CALL-ACTIVE. 

Upon reception of a D-TX GRANTED PDU indicating "transmission granted" or "transmission granted to another 
user", the CC sub-entity shall issue a CONFIGURE request primitive. The primitive shall carry as a parameter whether 
the transmit permission has been granted to this CC sub-entity or to another CC sub-entity, and to switch the U-Plane 
on. The MS given permission to transmit shall start timer T3 1 1 . If the D-TX GRANTED PDU indicates "transmission 
granted to another user" and contains the MS's own address as the transmitting party address then that MS should not 
switch to U-plane reception. However it shall not switch to U-plane transmission until it receives a D-TX GRANTED 
PDU indicating "transmission granted". 

Though the MS shall switch to U-Plane receive if it receives a "transmission granted to another user" response to its 
transmission request and the transmitting party address in the D-TX GRANTED PDU is not the MS's own address, the 
MS shall require an explicit response to its transmission request: one of "transmission granted", "transmission not 
granted" or "transmission queued". 

NOTE 1: The SwMI should either send the individually addressed D-TX GRANTED PDU ("transmission 

granted") first or supply the transmitting party address in the group addressed D-TX GRANTED PDU 
("transmission granted to another user") to prevent the MS that is about to be granted transmit permission 
switching to U-plane receive. As defined in EN 300 396-5 [24], clause 9, this is mandatory for the SwMI 
when granting transmit permission to a Direct Mode MS which is operating through a Direct Mode 
gateway. (This mandatory requirement applies only if the SwMI has accepted a request from the gateway 
to operate as a Direct Mode gateway.) 

Upon reception of a D-TX GRANTED PDU indicating "transmission granted to another user", and if the CC sub-entity 
has issued a U-TX DEMAND PDU to the lower layers and has not yet received a REPORT indication primitive 
indicating successful or unsuccessful transmission, then the CC sub-entity shall send a CANCEL request primitive to 
the lower layers to cancel transmission (and retransmissions) of that PDU. 

NOTE 2: The above procedure may sometimes stop retransmissions by the awarded MS as well as retransmissions 
by any other MSs that are requesting transmit permission. 

NOTE 3: If the SwMI queues any other transmission requests that it received then it should, at a convenient time, 
send D-TX GRANTED PDUs containing the "transmit request queued" parameter value to the MSs 
concerned. For transmission requests that are neither granted nor queued, and if the user application still 
wishes to transmit, then it has to send another TNCC-TX request primitive to the CC. 
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After reception of a D-TX GRANTED PDU indicating "transmission granted", and while it still has permission to 
transmit, the CC shall ignore any group addressed D-TX GRANTED or D-TX INTERRUPT PDUs it may receive (and 
any layer 2 channel assignment received with those PDUs by issuing an MLE-CONFIGURE request primitive ignoring 
the channel change, if requested). 

If the CC sends a U-TX DEMAND PDU whilst another MS is transmitting, the SwMI should normally wait for that 
party to finish the transmission (identified by the receipt of a U-TX CEASED PDU), before granting transmission 
permission to the other user application. On receipt of the U-TX DEMAND PDU, the SwMI may send 
a D-TX GRANTED PDU indicating whether the request-to-transmit is queued or rejected. Pre-emptive priority requests 
are dealt with in clause 14.5.2.2.1 f). 

The SwMI shall not send an unsolicited D-TX GRANTED PDU but it is recognized that a race/error condition may 
result in the MS receiving one. The CC may choose to follow an unsolicited individually addressed D-TX GRANTED 
PDU indicating "transmission granted" but if the CC does not want to transmit/send data then it shall use the 
U-TX CEASED PDU, as it does normally at the end of a speech or data item, to reject the transmission grant. 

c) Permission to transmit witlndrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or when the SwMI 
requires that the call should temporarily pause. In this case the SwMI should send a D-TX WAIT PDU to all MSs in 
that call (permitting or denying transmission requests according to the "transmission request permission" element). On 
reception of the D-TX WAIT PDU the CC sub-entity shall send a TNCC-TX indication primitive to the user application 
indicating that the transmission is waiting. The CC shall stop timer T3 11 , if activated, enter state WAIT, and send a 
CONFIGURE request primitive to switch the U-Plane off. The CC shall accept any layer 2 channel allocation and await 
further instructions on the channel that they have been directed to. 

If a request-to-transmit has been queued at the time when the D-TX WAIT PDU is received, the MS shall be allowed to 
withdraw its request-to-transmit by means of the U-TX CEASED PDU as described in clause 14.5.2.2.1 e). 

A group-addressed D-TX WAIT PDU shall apply to all the MSs in the call (including the transmitting MS). Optionally, 
the D-TX WAIT PDU may also be sent individually addressed to the transmitting MS enabling the SwMI to obtain a 
layer 2 acknowledgement from that MS. 

If the SwMI sends a D-TX WAIT PDU because it wishes to use an assigned channel for another call, it shall send a 
layer 2 channel allocation with the D-TX WAIT PDU directing the MS to a signalling channel other than the assigned 
channel. This is to prevent the change in usage marker associated with re-allocation of the assigned channel to the other 
call causing the waiting MS to drop the interrupted call. 

d) Permission to continue witin witindrawn call 
There are three cases as follows: 

1) If no MS was granted transmission at the time when the SwMI sent the D-TX WAIT PDU, or if an MS was 
granted transmission at the time of the D-TX WAIT PDU but the SwMI does not wish that transmission to 
continue, then either a D-TX CONTINUE PDU with the continue element set to "not continue", or 

a D-TX GRANTED PDU with the transmission grant element set to "transmission not granted", shall be sent 
as a group message to all MSs in the group. The CC shall accept any layer 2 channel allocation. All CC 
sub-entities shall return to state CALL-ACTIVE but the U-plane shall not be switched on and the MS shall 
assume that any previous transmission permission no longer applies. If the D-TX CONTINUE PDU contains 
an indication that the MS is allowed to request transmission permission, it may follow the transmission control 
procedures described in clause 14.5.2.2.1 a). 

2) If there was one MS granted transmission at the time when the SwMI sent the D-TX WAIT PDU, and if the 
SwMI wishes that transmission to continue, then either a D-TX CONTINUE PDU with the Continue element 
set to "continue" shall be sent as a group message to the group, or a D-TX GRANTED PDU with the 
transmission grant element set to "transmission granted" shall be sent to the granted MS and 

a D-TX GRANTED PDU with the transmission grant element set to "transmission granted to another" shall be 
sent as a group message to the group. The CC shall accept any layer 2 channel allocation. If 
a D-TX CONTINUE PDU with the Continue element set to "continue" is sent, it shall give the earlier granted 
MS permission to continue transmission. The MS granted permission to transmit shall start timer T31 1. All CC 
sub-entities shall return to state CALL ACTIVE and shall send a CONFIGURE request primitive to the lower 
layers to switch the U-plane on. 
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A group-addressed D-TX CONTINUE PDU shall apply to all the MSs in the call (including the awarded MS). 
Optionally, the D-TX CONTINUE PDU may also be sent individually addressed to the awarded MS enabling 
the SwMI to obtain a layer 2 acknowledgement from that MS. 

3) If there was one MS granted transmission at the time when the SwMI sent the D-TX WAIT PDU but the 

SwMI wishes to give the transmission permission to the other party or if no MS was granted transmission at 
the time when the SwMI sent the D-TX WAIT PDU and the SwMI wishes to give the transmission permission 
now to one party, the SwMI may first send a D-TX CONTINUE PDU. If a MS has requested permission to 
transmit during the period when the transmission was withdrawn, the SwMI should first send 
a D-TX CONTINUE PDU as a group message with the Continue element set to "not continue". 
A D-TX GRANTED PDU should then be sent as an individual message to the granted MS with information 
element transmission grant set to "transmission granted" and as a group message to the rest of the group with 
information element transmission grant set to "transmission granted to another user". When receiving either 
D-TX CONTINUE or D-TX GRANTED PDU the CC sub-entity shall return to state CALL- ACTIVE. In 
addition when receiving D-TX GRANTED PDU CC shall send a CONFIGURE request primitive to the lower 
layers to switch the U-plane on. 

If the MS is in state WAIT and it receives a D-TX GRANTED PDU, it shall return to state CALL-ACTIVE 
and obey the instruction in the D-TX GRANTED PDU. 

e) End of Transmission 

At the end of a transmission the user application shall send a TNCC-TX request primitive to the TNCC-SAP indicating 
ceased transmission. The CC sub-entity shall send this information in a U-TX CEASED PDU and stop timer T311. The 
CC shall send the U-TX CEASED PDU with the stealing permission set to "immediate stealing" and the stealing 
repeats flag set. Upon reception of the U-TX CEASED PDU, the SwMI normally sends a D-TX CEASED PDU to the 
group informing the group members that the transmission has now ceased. 

Upon reception of a D-TX CEASED PDU the CC shall send this information to the user application in 

a TNCC-TX indication primitive (transmission ceased) and the CC shall send a CONFIGURE request primitive to the 

lower layers to switch the U-Plane off, see figure 14.18. 

Also, if the CC that is sending the U-TX CEASED PDU receives a REPORT indication of either successful or 
unsuccessful transmission of that PDU by the lower layers, then it shall behave as if it had received a D-TX CEASED 
PDU i.e. it shall send a TNCC-TX indication (transmission ceased) to the user application and shall send 
a CONFIGURE request primitive to the lower layers to switch the U-Plane off. If a D-TX CEASED PDU is received 
but no REPORT indication of successful transmission of the U-TX CEASED PDU then the CC shall send a CANCEL 
request primitive to the lower layers to stop retransmissions of the U-TX CEASED PDU. 

NOTE 4: The requirement for the CC to cancel retransmissions may apply if the SwMI sends only 

a group-addressed D-TX CEASED PDU and the transmitting MS does not receive a layer 2 
acknowledgement. 

If there was a request for transmission already queued in the SwMI when the U-TX CEASED PDU was received, the 
SwMI may send a D-TX GRANTED PDU as an individual message to the granted MS and another D-TX GRANTED 
PDU as a group message to the rest of the group as described in clause 14.5.2.2.1. b), without sending an explicit 
D-TX CEASED PDU. However, the SwMI should first send at least a layer 2 acknowledgement to the MS that sent the 
U-TX CEASED PDU so that the MS can stop its U-plane transmission and start accepting group addressed 
D-TX GRANTED PDUs. 

The SwMI shall not send an unsolicited, individually addressed D-TX CEASED PDU but it is recognized that a 
race/error condition may result in the MS receiving one. If CC receives an unsolicited, individually addressed 
D-TX CEASED PDU it shall send this information further on to the user application in a TNCC-TX indication 
primitive (transmission ceased) and shall send a CONFIGURE request primitive to the lower layers to switch the 
U-Plane off. 
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f) Stop-transmission order 



If a MS wishes to interrupt the transmitting MS with a pre-emptive priority request, it shall send a U-TX DEMAND 
PDU indicating the level of priority in the "TX demand priority" element. If the SwMI supports transmission 
interruption, it shall send a D-TX INTERRUPT PDU to the MS which currently has permission to transmit. Upon 
reception of an individually addressed D-TX INTERRUPT PDU the CC sub-entity shall remain in state 
CALL- ACTIVE, and shall stop timer T3 11 . The CC shall send information to the user application in a TNCC TX 
indication primitive indicating transmission interrupt and the CC sub-entity shall send a CONFIGURE request primitive 
to the lower layers to switch the U-Plane accordingly (see clause 14.5.2.4). 

The SwMI should send a D-TX INTERRUPT PDU as a group message to the rest of the group indicating that the 
permission to transmit has been (or will be) allocated to another user, see figure 14.18. Upon reception of the 
D-TX INTERRUPT PDU the CC sub-entity shall remain in state CALL ACTIVE and shall send a TNCC-TX indication 
primitive to the user application indicating transmission interrupt. The SwMI should then send a D-TX GRANTED 
PDU as an individual message to the MS that requested the priority transmission. 

The D-TX INTERRUPT PDU shall indicate that transmission is granted to another user and then the MS shall switch to 
(or remain in) U-plane reception. Otherwise, if there is a delay before the pre-emptive priority transmission, the SwMI 
may indicate "transmission not granted" in the D-TX INTERRUPT PDU. Then the MS shall switch the U-plane off and 
wait for a D-TX GRANTED PDU. 

g) Expiry of timer T31 1 : call transmission timer. 

Upon expiry of timer T3 1 1 , CC shall remain in state ACTIVE, shall send a TNCC-TX indication primitive to the user 
application and a U-TX CEASED PDU to the peer entity. 

14.5.2.2.2 Call status information procedures 

The D-INFO PDU can be used for carrying call status messages from SwMI to the MS. When a D-INFO PDU is 
received, depending on the notification, the following actions are taken by CC: 

a) call in queue 

When the SwMI has put a call into a queue, if the D-INFO PDU contains a value for the call time-out, set-up phase, the 
CC shall start timer T302 using that value. The CC shall send the information further on to the application in a TNCC- 
NOTIFY indication primitive. If the call is queued at call set-up time the D-INFO PDU should be preceded by a 
D-CALL PROCEEDING PDU; 

b) call is proceeding 

This may be sent to the calling user application during the call set-up phase to indicate that the call set-up time will be 
longer than for a normal call set-up. The information that the call time-out, set-up phase value shall be changed is made 
available to the CC sub-entity in the D-INFO PDU. The CC shall start T302 using the new timer value. The CC shall 
send the information further on to the application in a TNCC-NOTIFY indication primitive; 

c) prolonging the call time-out time 

The following text describes prolonging the call time-out time: 

• the SwMI may decide to change the call time-out time by sending a D-INFO PDU with a new T310 value. 
Upon reception of the D-INFO PDU containing the "call time-out" element, T310 shall be started using the 
defined value. If the SwMI supplies a T310 value in the D-INFO PDU, it shall set the value of the "reset call 
time-out timer" element of the PDU to indicate reset of T310; 

• the SwMI may also choose to reset the call time-out time and start it again using the current defined value. 
Upon reception of the D-INFO PDU with the "reset call time-out timer" element indicating that T310 shall be 
reset, T310 shall be started using the value defined earlier; 



• 



in either case, the Timer value shall be sent further on to the application in a TNCC-NOTIFY indication 
primitive; 
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• the SwMI may also change the call timeout time during call restoration by supplying the "call time-out" 

element in the D-CALL RESTORE PDU, refer to clause 14.5.2.2.4. If the SwMI supplies a T310 value in the 
D-CALL RESTORE PDU, it shall set the value of the "reset call time-out timer" element of the PDU to 
indicate reset of T3 10. 

Most downlink CC PDUs may contain a Notification indicator information element (in addition to the D-INFO PDU) 
and SwMI may inform calling/called user about offered or connected service using the Notification indicator 
information element. CC may send this notification to the application in corresponding TNCC service primitive. 

When a Notification indication is received following actions are taken by CC: 

Limited group coverage: 

At the call set-up SwMI may inform that it is connecting a group call that covers a smaller area than expected. It may be 
used during a call to indicate that the group coverage is made smaller. CC may send this notification to the application 
using TNCC-NOTIFY indicator service primitive. 

NOTE: The expected area could be pre-defined, defined by the Area selection supplementary service or known 
by other means that are outside the scope of the present document. 

14.5.2.2.3 Call modification procedures 

The MS service user may modify the service of an existing call. To initiate a modification the user application shall 
issue a TNCC -MODIFY request primitive and the CC sub-entity shall send a U-INFO PDU and wait for a D-INFO 
PDU from the SwMI before changing any of the current service parameters. The SwMI should not send D-INFO PDU 
to modify a service while an ongoing U-Plane transmission is in progress. 

When a service has been changed by the SwMI, the SwMI should indicate this to all parties by issuing the D-INFO 
PDU. Upon reception of a D-INFO PDU indicating an acceptable service modification the CC sub-entity shall send it to 
the application in a TNCC -MODIFY indication primitive, and the CC sub-entity shall send a CONFIGURE request 
primitive for lower layer configuration. 

If the SwMI is unable to provide the requested service, it should either send a D-INFO PDU to the requesting party 
containing the current service (unchanged), or send a D-INFO PDU to all parties containing an alternative service. For 
example, if a user application requests an increase from a 1-slot per frame call to a 4-slots per frame call, and the SwMI 
is unable to allocate more than 2 slots to the call, it may offer a 2-slots per frame call in the D-INFO PDUs. 

The service may be changed between any combination of one or more of the following: 

a clear call may be changed to an encrypted call; or 

an encrypted call may be changed to a clear call; 

a 4-slots-per-frame call may be changed to a 1-slot, 2-slot or 3-slot call; 

a 3-slot call may be changed to a 1-slot, 2-slot or 4-slot call; 

a 2-slot call may be changed to a 1-slot, 3-slot or 4-slot call; 

a 1-slot call may be changed to a 2-slot, 3-slot or 4-slot call; 

a circuit mode type (TCH/S, TCH/7.2, TCH/4.8 or TCH/2.4) may be changed to a different circuit mode type 
(with the requested interleaving depth in the case of TCH/4.8 or TCH/2.4); 

a protected circuit mode data type (TCH/4.8 or TCH/2.4) may be changed to a different interleaving depth 
from the set of permissible values (N = 1, 4 or 8). 

NOTE: The clear and encrypted calls refer to the end-to-end clear and encrypted calls. The end-to-end encryption 
control is independent of the air interface encryption control. 

It is also possible to change between the circuit mode speech teleservice and a circuit mode unprotected (speech, 
encrypted) bearer service. 
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The encryption state of each transmission, defined using D-TX GRANTED, can be set independently by the encryption 
control element in the U-TX DEMAND PDU. The SwMI should not change the requested encryption state in the 
responding D-TX GRANTED PDU from that requested in the U-TX DEMAND PDU. 

If the MS cannot support a new service combination indicated by D-INFO, D-TX GRANTED or D-TX INTERRUPT, 
the user application or the CC as appropriate shall disconnect or leave the call, refer to clause 14.5.2.3. The 
U-DISCONNECT PDU shall contain disconnection cause "requested service not available". In case the rejection results 
from unsupported encryption flag state the disconnect cause shall be "Called party does not support encryption" or 
"Called party requires encryption". 



14.5.2.2.4 
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Figure 14.19: Group call - successful call restoration 
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Figure 14.20: Group call - unsuccessful call restoration 

Call restoration of a group call shall only take place in the CC sub-entity when the CC has entered state 

CALL- ACTIVE. The CC sub-entity should keep information on whether it is active in a group call or an individual call. 

When the CC receives a BREAK indication primitive, the CC shall switch the U-Plane off as described in 

clause 14.5.2.4 and shall remain in state CALL- ACTIVE. If the CC had permission to transmit/send data at that time the 

CC shall assume that the permission is now ended as if the CC had sent a U-TX CEASED PDU. If the MS is in state 

WAIT when it receives a BREAK indication primitive then it shall behave as if it had received a D-TX CONTINUE 

PDU with the continue element set to "not continue". It shall then obey the instructions in the D-CALL RESTORE 

PDU. 
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If the CC receives a RESUME indication primitive indicating that the C-Plane may now be used again, it shall issue 
a U-CALL RESTORE PDU containing the GSSI or GTSI and the call identifier of the call which CC wants to restore. 
If a temporary address is used in the call then it shall be used as the GSSI. If the MS is participating in a call within a 
group that does not belong to current network (e.g. the MS has migrated and the group belongs to its home network) the 
CC shall use the full GTSI of the group in the U-CALL RESTORE PDU.Jf the CC wishes to continue transmission in 
the new cell, or keep a queued transmission request valid in the new cell, it shall indicate so in the request to 
transmit/send data information element in the U-CALL RESTORE PDU. A MS which has requested for transmit 
permission on a previous cell and has received a "transmission request queued" response or no response at all on that 
cell, may either refresh the transmission request by requesting for transmit permission in the U-CALL RESTORE PDU 
on the new cell, or withdraw the transmission request by requesting for receive permission in the U-CALL RESTORE 
PDU on the new cell. A MS which attempts call restoration having received a "transmission request queued" indication 
on a previous cell can assume that its transmission request is still held in the SwMI's queue unless the MS receives a 
"transmission not granted" indication within the call restoration signalling. After sending a U-CALL RESTORE PDU, 
the CC shall start Timer T307 and wait for a D-CALL RESTORE PDU. 

When the CC receives a D-CALL RESTORE PDU, timer T307 shall be stopped and the call shall be resumed with the 
new parameters, see figure 14.19. The CC shall obey the transmission granting in the transmission grant information 
element, refer to clause 14.5.2.2. L Timer T310 shall be reset and started only if the "Reset call timeout" information 
element value is 1 (Reset call time-out timer T310); the T310 value shall be taken from the D-CALL RESTORE PDU 
call timeout information element and, if not present in the PDU, from the previous value (provided in D-CONNECT, 
D-CONNECT ACKNOWLEDGE, D-SETUP or D-INFO PDU). If appropriate the CC shall issue a CONFIGURE 
request primitive to switch the U-Plane on using the procedure in clause 14.5.2.4. 

If a MS restores to a cell without requesting for transmit permission and receives an individually addressed 
D-CALL RESTORE PDU with "Call status" element having value "Call is queued" (indicating that the cell has no 
available traffic resources), the value of the "Transmission grant" element in the D-CALL RESTORE PDU shall be 
"Transmission not granted". If the call subsequently proceeds to traffic (it may be cleared while queued), the MS shall 
expect to receive one of the following PDUs; the MS shall then expect no further signalling for the call restoration: 



• 



• 



group or individually addressed D-TX GRANTED PDU, containing a layer 2 channel allocation, with 
"Transmission grant" element having value "Transmission granted to another user". The MS shall switch the 
U-plane on; the MS is authorized to receive traffic; 

group or individually addressed D-TX GRANTED PDU, containing a layer 2 channel allocation, with 
"Transmission grant" element having value "Transmission not granted". The MS shall retain its current 
U-plane state (and shall perform the channel change). 

If a MS restores to a cell, requests for transmit permission, and receives an individually addressed D-CALL RESTORE 
PDU with "Call status" element having value "Call is queued" (indicating that the cell has no available traffic 
resources), the value of the "Transmission grant" element in the D-CALL RESTORE PDU shall be either 
"Transmission request queued" (MS shall wait for further signalling to indicate the result of its request to transmit) or 
"Transmission not granted" (MS's request to transmit is rejected). If the call subsequently proceeds to traffic (it may be 
cleared while queued), the MS shall expect to receive one of the following PDUs: 

• group or individually addressed D-TX GRANTED PDU, containing a layer 2 channel allocation, with 
"Transmission grant" element having value "Transmission granted to another user". The MS shall switch the 
U-plane on; the MS is authorized to receive traffic; the MS shall, if its request to transmit was not rejected by 
the "Call is queued" D-CALL RESTORE PDU, wait for further signalling to indicate the result of its request to 
transmit; 

• group or individually addressed D-TX GRANTED PDU, containing a layer 2 channel allocation, with 
"Transmission grant" element having value "Transmission not granted". The MS shall retain its current 
U-plane state (and shall perform the channel change); the MS's request to transmit, if still outstanding 
following receipt of the "Call is queued" D-CALL RESTORE PDU, is rejected; 

• individually addressed D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission 
grant" element having value "Transmission request queued". The MS shall not switch the U-plane on (but shall 
perform the channel change); the MS shall wait for further signalling to indicate the result of its request to 
transmit. The SwMI shall not use this value of the "Transmission grant" element if the "Call is queued" 
D-CALL RESTORE PDU rejected the MS's request to transmit; MS behaviour if it receives such a response in 
this context is outside the scope of the present document; 
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• individually addressed D-TX GRANTED PDU, containing a layer 2 channel allocation, with "Transmission 
grant" element having value "Transmission granted". The MS shall switch the U-plane on; the MS is 
authorized to transmit. The SwMI shall not use this value of the "Transmission grant" element if the "Call is 
queued" D-CALL RESTORE PDU rejected the MS's request to transmit; MS behaviour if it receives such a 
response is described in clause 14.5.2.2.1 b) (refer to text describing handling of unsolicited transmission 
grant). 

The call length timer T310 shall continue running during the call restoration and on expiry of T310, the procedure 
defined in clause 14.5.2.3.4 shall apply. 

If the call cannot be restored the CC shall receive a REOPEN indication primitive indicating that the call is lost. 

Upon reception of REOPEN indication primitive or on expiry of timer T307, the CC shall then stop all T3xx timers, 

clear the call identifier and temporary group address if applicable, and return to state IDLE and it shall send 

a TNCC-RELEASE indication primitive to the user application with the cause for disconnection, see figure 14.20. 

If the SwMI provides a new call identifier with the D-CALL RESTORE PDU, CC shall use it in all subsequent 
signalling relating to that call. The MS shall not send any other call related signalling than U-CALL RESTORE PDU, 
after a cell change, before it has received a D-CALL RESTORE PDU (and possible new call identifier) from the SwMI. 

A MS which is queueing for a traffic channel during restoration and which has an outstanding transmission request, 
may cancel that transmission request by sending a U-TX CEASED PDU. A MS which is queueing for a traffic channel 
during restoration and which does not have an outstanding transmission request, may make a transmission request by 
sending a U-TX DEMAND PDU, providing the SwMI has not disallowed transmission requests (via the "transmission 
request permission" element). 

If there is more than one circuit mode call active at the time when the MLE-BREAK indication primitive was received, 
each call shall be restored separately and hence U-CALL RESTORE and D-CALL RESTORE PDUs shall be 
exchanged one by one for each call. 

14.5.2.2.5 DTMF procedures 

When a user application requires to transfer DTMF digits to other user applications during a circuit mode call, it shall 
issue a TNCC-DTMF request primitive to the CC entity. The DTMF protocol to be used is specified is 
clause 14.5.1.2.5. 

NOTE 1: The DTMF signalhng can be used only after either a D-CONNECT or D-SETUP PDU has been received 
and the TETRA call is established. 

NOTE 2: DTMF signalling may not function correctly during a group call (group addressed basic link LLC 

acknowledged service is required). The support of DTMF signalling during group calls is outside the 
scope of the present document. 

1 4.5.2.2.6 Temporary address handling procedures 

The SwMI may allocate a temporary group address for a group call in a D-CONNECT, D-SETUP, D-CALL RESTORE 
or D-INFO PDU. The temporary address shall be a valid layer 2 address in the MS for reception of group addressed 
messages for the duration of the call. 

In addition, if the MS calls a group that is not attached in the MS (i.e. the group address is not a valid layer 2 address) 
when it is registered in the home SwMI of that group, and if the D-CONNECT PDU does not contain the temporary 
address element, then the MS shall implicitly assume temporary membership of the called group address for the 
duration of the call. This temporary membership shall apply only after receipt of the D-CONNECT PDU. However, if 
the D-CONNECT PDU contains the basic service information element with the communication type sub-element 
indicating "point to point" then the MS shall not adopt the called address as a temporary address. If the call was set up 
using a SNA, the calling MS shall not implicitly assume temporary membership of the called group address to which 
the SNA corresponds; this restriction is imposed because the MS may not know the called group address to which the 
SNA corresponds, in which case it cannot assume temporary membership of the group. 
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NOTE 1 : If the S wMI is unsure whether the group address for the call is a valid layer 2 address for the calling MS, 
the SwMI should allocate the group address as a temporary address to the calling MS; this 
recommendation is made because if the group address for the call is not a valid layer 2 address, and the 
SwMI doesn't allocate the group address for the call as a temporary address, the MS will participate in the 
call but will ignore all group addressed call maintenance signalling. 

NOTE: 2 In this procedure, if the MS calls a group that it is not a member of (when it is registered in the home 
SwMI of that group) then it may assume temporary membership of the called group address without 
having received a temporary address element in the D-CONNECT PDU. If the calling user has made an 
erroneous selection of communication type then this could result in the calling MS adopting another MS's 
individual address as a temporary group address. Therefore the SwMI should check that the called 
address in a requested group call is actually a group address; if it is not then the SwMI should either 
disconnect the call or correct the communication type to "point to point" when sending the D-CONNECT 
PDU (the SwMI may also choose to correct the communication type to "point to point" in 
a D-CALL PROCEEDING, D-INFO or D-ALERT PDU). 

The CC sub-entity shall send a CONFIGURE request primitive informing the lower layers of the new temporary 
address and if required the change of basic service from individual to group call. 

When the call is then released, the CC sub-entity shall send a CONFIGURE request primitive informing the lower 
layers that the temporary group address is not longer valid (see clause 14.5.2.3). 



14.5.2.2.7 



Calls to and from external subscribers 



An external subscriber can call TETRA group numbers. The signalling needed between an external subscriber and a 
gateway is outside the scope of the present document. The signalling between the SwMI and the called group is the 
same as that for a mobile originated group call. 

14.5.2.3 Call disconnection procedures 
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Figure 14.21 : Group call - request-to-disconnect 
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Figure 14.22: Group call - group member leaves ongoing group call 



14.5.2.3.1 



User initiated disconnection 



A user application may initiate call disconnection at any state of a call by sending a TNCC-RELEASE request primitive 
to the CC sub-entity. A call owner shall signal call disconnection to the SwMI by sending a U-DISCONNECT PDU. A 
non-call owner shall leave a call without disconnecting it. In that case there shall not be any disconnection related 
signalling from the MS to the SwMI. The disconnect type parameter in the TNCC-RELEASE request primitive 
indicates whether the CC should disconnect the call or leave the call without disconnection. Refer to clause 14.5.2.7 for 
the definition of call ownership. 

The following procedures shall apply to the user application that is designated as the call owner, figure 14.21 refers: 

• during call set-up phase until U-SETUP PDU has been transmitted to the SwMI, a disconnection can be 
handled locally using a CANCEL request primitive. Information regarding the local progress of the 
transmission of a PDU is received in REPORT indication primitives. After a local cancellation the CC 
sub-entity shall stop timer T303 and shall return to state IDLE; 

• on receipt of a TNCC-RELEASE request primitive in the CC sub-entity from the user application requesting 
call disconnection, the CC shall send a U-DISCONNECT PDU, start timer T308 and enter state 
CALL-DISCONNECT. All other T3xx Timers shall be stopped. The progress of the disconnection shall be 
reported to the CC with REPORT indication primitive; 

• Should the user application disconnect the call during the window between transmission of a U-SETUP and 
reception of a D-CALL PROCEEDING or D-CONNECT PDU (i.e. before the MS has received a call 
identifier for the call), it shall use the dummy call identifier (all zeroes); 

• if a U-DISCONNECT is issued, CC shall await a D-RELEASE PDU. When a D-RELEASE PDU or a 
REPORT indication primitive with reason PDU transfer failed is received, or timer T308 expires, the CC 
sub-entity shall clear the call identifier, stop timer T308 and return to state IDLE, issuing a TNCC-RELEASE 
confirm primitive to the user application. The CC sub-entity shall send a CONFIGURE request primitive to 
the lower layers to clear the temporary group address (if the temporary address is applicable to the call), switch 
the U-Plane off, reject any pending channel change response request for that call (refer to clause 14.5.3.2), and 
leave the assigned channel (if the MS is on an assigned channel when the CONFIGURE request primitive is 
sent). If a channel change response is required for the D-RELEASE PDU, CC shall accept that channel change 
(refer to clause 14.5.3.2). The SwMI may also choose to send only a group address D-RELEASE PDU and the 
CC shall behave as if it had received it individually addressed. 

The SwMI should inform the other MSs in the call of the call clearance using a D-RELEASE PDU (see 
clause 14.5.2.3.3 for MS actions). 

If a group participant wishes to leave the group call, without disconnecting the call, the user application shall issue a 
TNCC-RELEASE request primitive with disconnect type parameter equal to "leave call without disconnection": 

• if the user leaves the call without disconnection, the CC sub-entity shall clear the call identifier, stop all T3xx 
Timers and return to state IDLE, see figure 14.22. The CC sub-entity shall send a CONFIGURE request 
primitive to the lower layers to clear the temporary group address (if the temporary address is applicable to the 
call), switch the U-Plane off, reject any pending channel change response request for that call (refer to 
clause 14.5.3.2), and leave the assigned channel (if the MS is on an assigned channel when the CONFIGURE 
request primitive is sent). 
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14.5.2.3.2 Network initiated disconnection 

In the case where the SwMI cannot support a request for a call from the calling MS, the SwMI shall send a 
D-RELEASE PDU containing the reason for disconnection, to the calling MS. 

In the case where the SwMI can no longer support an established call, the SwMI should send a D-RELEASE PDU to all 
the MSs in the group containing the reason for disconnection, and subsequently release the call. 

The MS actions are defined in clause 14.5.2.3.3. 

14.5.2.3.3 Reception of disconnection request 

The BS may send a disconnection request at any phase of the call and the MS shall react as follows: 

• when the CC sub-entity receives a D-RELEASE PDU the CC shall not send any response; 

• the CC shall inform the user application with a TNCC-RELEASE indication primitive, clear the call identifier, 
stop all T3xx timers and enter state IDLE, refer figure 14.21. The CC sub-entity shall send a CONFIGURE 
request primitive to the lower layer to clear the temporary group address (if the temporary address is 
applicable to the call), switch the U-Plane off, reject any pending channel change response request for that call 
(refer to clause 14.5.3.2), and leave the assigned channel (if the MS is on an assigned channel when the 
CONFIGURE request primitive is sent). If a channel change response is required for the D-RELEASE PDU, 
CC shall accept that channel change (refer to clause 14.5.3.2). 

14.5.2.3.4 Colliding disconnection 

If the CC entity receives a D-RELEASE PDU when CC has just sent a U-DISCONNECT PDU, the CC sub-entity shall 
release the call immediately as defined in 14.5.2.3.3. In addition, the CC shall issue a CANCEL request primitive to the 
lower layers to cancel any ongoing re-transmission of the U-DISCONNECT PDU. 

1 4.5.2.3.5 Expiry of timers 

a) Timer T302: call set-up timer for calling MS 

Upon expiry of timer T302, CC shall send a TNCC-RELEASE indication primitive to the user application, send a 
U-DISCONNECT PDU, and follow the procedures in clause 14.5.2.3.1. The value of the disconnect cause element shall 
be set to "expiry of timer". 

b) Timer T303: call initiated timer for calling MS 

Upon expiry of timer T303, CC shall send a TNCC-RELEASE indication primitive to the user application, send a 
U-DISCONNECT PDU, and follow the procedures in clause 14.5.2.3.1. The value of the disconnect cause element shall 
be set to "expiry of timer". 

c) Timer T307: call restoration timer for point-to-multipoint calls 

Upon expiry of timer T307, CC shall apply procedures described in clause 14.5.2.2.4. The value of the disconnect cause 
element shall be set to "expiry of timer". 

d) Timer T308: call disconnect timer 

Upon expiry of timer T308, CC shall return to state IDLE, send a TNCC-RELEASE confirm primitive to the user 
application and shall send a CANCEL request primitive to the lower layers to cancel the sending of the 
U-DISCONNECT PDU. The CC sub-entity shall send a CONFIGURE request primitive to the lower layers to clear the 
temporary group address (if the temporary address is applicable to the call), switch the U-Plane off, reject any pending 
channel change response request for that call (refer to clause 14.5.3.2), and leave the assigned channel (if the MS is on 
an assigned channel when the CONFIGURE request primitive is sent). 
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e) Timer T31 0: call length timer 



Upon expiry of timer T310, if the MS is the call owner, the CC shall send a TNCC-RELEASE indication primitive to 
the user application, send a U-DISCONNECT PDU and follow the procedures in clause 14.5.2.3.1. The value of the 
disconnect cause element shall be set to "expiry of timer". 

If the MS is not the call owner, CC shall return to state IDLE, and shall send a TNCC-RELEASE indication primitive to 
the user application and a CONFIGURE request primitive to the lower layers. The value of the disconnect cause 
element shall be set to "expiry of timer". 

f) Timer T31 1 : call transmission timer 
Refer to clause 14.5.2.2.1 g). 

g) Timer T330: call set-up delay timer 

Upon expiry of timer T330 CC can no longer accept the corresponding channel change. 

14.5.2.4 U-Plane switching 

The U-Plane switching procedure ensures that traffic/signalling synchronization between the CMCE and the MAC shall 
be maintained during the lifetime of a call. The CC informs the MAC when it has permission to transmit traffic 
(i.e. TCH or STCH) and when to stop. The CC also informs the MAC when it may process received traffic (and when to 
stop). The latter procedure also assists the MAC to interpret when the received bit-stream on the assigned channel is 
TCH/STCH and when it is SCH. 

The CC changes the U-plane operation in the MAC by issuing the CONFIGURE request primitive, indicating "Switch 
U-plane = On" or "Switch U-plane = Off, "Tx grant = true" or "Tx grant = false" and "Simplex/duplex = simplex". 
There shall be only three valid combinations. 

1) Switch U-plane = On, Tx grant = true. Simplex/duplex = simplex: 

MS is authorized to transmit traffic. 

2) Switch U-plane = On, Tx grant = false. Simplex/duplex = simplex: 

MS is authorized to receive traffic. 

3) Switch U-plane = Off: 

withdraws previous authorization to transmit and/or receive traffic. 

1 4.5.2.4.1 End of call set-up phase 

When the CC in a MO call receives a D-CONNECT PDU or when the CC in a MT call receives a D-SETUP PDU, it 
shall issue a CONFIGURE request primitive to the lower layers containing information about the call e.g. the type of 
traffic, the interleaving depth, the call identifier and whether the call is end-to-end encrypted. 

If the transmission grant element in the D-CONNECT PDU is set to "transmission granted" then the CONFIGURE 
request primitive shall contain the parameter value "Switch U-Plane = On" and "Tx grant = true" to indicate that the 
MAC has permission to transmit traffic. If the transmission grant element is set to "transmission granted to another 
user" then the CONFIGURE request primitive shall contain the parameter value "Switch U-Plane = On" but shall 
contain "Tx grant = false" to indicate that the MAC should receive traffic. For the other values of the transmission grant 
element, the U-plane shall not be switched on. 

If the transmission grant element in the D-SETUP PDU is set to "transmission granted to another user" then the 
CONFIGURE request primitive shall contain the parameter value "Switch U-Plane = On" but shall contain 
"Tx grant = false" to indicate that the MAC should receive traffic. For the other values of the transmission grant 
element, the U-plane shall not be switched on. 
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The only valid values of the transmission grant element in a group-addressed PDU shall be "transmission granted to 
another user" and "transmission not granted". 

14.5.2.4.2 During call maintenance phase 

a) Transmission grant control 

When the CC does not have permission to transmit, and if it receives a D-TX GRANTED PDU with the transmission 
grant element set to "transmission granted" or "transmission granted to another user", then the CC shall send a 
CONFIGURE request primitive containing the parameter "Switch U-Plane = On" and indicating whether the MAC has 
permission to transmit traffic ("Tx grant = true" or "Tx grant = false" respectively). For the other values of the 
transmission grant element, the U-plane state shall not be changed. 

While the CC has permission to transmit, it shall ignore group addressed D-TX GRANTED PDUs (see 
clause 14.5.2.2.1b)). 

b) Transmission ceased 

When the CC receives a D-TX CEASED PDU or on receipt of a REPORT indication primitive of either successful or 
unsuccessful transmission of a U-TX CEASED PDU, the CC shall issue a CONFIGURE request primitive containing 
the parameter value "Switch U-Plane = Off. 

c) Temporary pause. 

When the CC receives a D-TX WAIT PDU, and if the U-plane is currently switched on for either transmission or 
reception, the CC shall issue a CONFIGURE request primitive containing the parameter value "Switch U-plane = Off. 

When the CC receives a D-TX CONTINUE PDU then: 

• if the continue element is set to "continue" and the MS had permission to transmit traffic at the time of receipt 
of the D-TX WAIT PDU, then the CC shall issue a CONFIGURE request primitive containing the parameter 
values "Switch U-Plane = On" and "Tx grant = true"; 

• if the continue element is set to "continue" and the MS did not have permission to transmit traffic at the time of 
receipt of the D-TX WAIT PDU, then the CC shall issue a CONFIGURE request primitive containing the 
parameter value "Switch U-Plane = On" but containing "Tx grant = false". 

If the Continue element is set to "not continue" then the U-plane shall not be switched on. 

d) Interruption 

When the CC receives a D-TX INTERRUPT PDU, and if the transmission grant element is set to "transmission granted 
to another user", then the CC shall issue a CONFIGURE request primitive containing the parameter value "Switch 
U-Plane = On" but containing "Tx grant = false" to indicate that the MAC should receive traffic. For the other values of 
the transmission grant element, the CC shall issue a CONFIGURE request primitive containing the parameter value 
"Switch U-Plane = Off". 

While the CC has permission to transmit, it shall ignore group addressed D-TX INTERRUPT PDUs. 

e) Call restoration 

When CC receives a BREAK indication primitive indicating that a temporary break in the radio link has occurred, the 
CC shall issue a CONFIGURE request primitive containing the parameter value "Switch U-Plane = Off". 

When CC receives a D-CALL RESTORE PDU indicating that the call has now been restored after a temporary break in 
the radio link, and if the transmission grant element is set to "transmission granted" or "transmission granted to another 
user", then the CC shall issue a CONFIGURE request primitive containing the parameter value "Switch U-Plane = On" 
and indicating whether the MS has permission to transmit traffic ("Tx grant = true" or "Tx grant = false" respectively). 
For the other values of the transmission grant element, the U-plane shall not be switched on. 



ETSI 



251 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 



14.5.2.4.3 Call disconnection phase 



When the CC receives a D-RELEASE PDU, or if it receives a REPORT indication primitive of either successful or 
unsuccessful transmission of a U-DISCONNECT PDU, or if it receives a TNCC-RELEASE request primitive from the 
user application indicating that the user wishes to leave the call (without disconnecting the call), then the CC shall issue 
a CONFIGURE request primitive to the lower layers containing the parameter value "Switch U-Plane = Off". 

14.5.2.5 Void 

14.5.2.6 Acknowledged group call procedures 

The MS procedures for handling of an acknowledged group call shall be in accordance with the procedures described 
for a normal group call in clauses 14.5.2.1 to 14.5.2.4 with the following additions, which for the SwMI side are 
informative. 

The SwMI should poll the individuals within the called group on the traffic channel after call set-up. 

It is an operator option defined in the SwMI if the call should proceed immediately by giving the calling user 
permission to transmit before, during or after the called members of the group have been polled on the traffic channel. 

The SwMI may optionally use one of the following criteria for giving the calling user permission to transmit: 

• the D-SETUP PDU has been sent to the called users and the polling will take place in parallel with the ongoing 
call; 

• a certain number of users have responded to the poll; 

• all users have been polled. 

As a poll request, all MS shall be prepared to receive a D-INFO PDU during the call from the SwMI. 

Upon reception of a D-INFO PDU indicating a poll request the CC entity shall send this information further on to the 
user in a TNCC -NOTIFY and send a U-INFO PDU to the SwMI. The U-INFO shall be sent immediately by the CC on 
receipt of the poll request, see figure 14.17. 

As an operator option the SwMI may disconnect the call after a certain time if insufficient number of members are 
present, before the permission to transmit is given. 

It is a SwMI option how and when to inform the calling user or any other user the result of the polling. An MS shall, 
during the call set-up phase or during an ongoing call, be prepared to receive one or more D-INFO PDU with the 
following alternative poll results: 

• percentage of responding number of group members; 

• number of responding group members; 

• list of identities of the responding group members. 

The CC shall send the poll result in the D-INFO PDU to the user application in a TNCC NOTIFY indication primitive. 

14.5.2.7 Call ownership 

The CC states and state transitions described in this clause are defined in clause 14.4.2. 

Upon entry to the MO-CALL-SETUP state from the IDLE state, the MS shall assume it is a call owner. 

Upon entry to the MT-CALL-SETUP state from the IDLE state, the MS shall assume it is not a call owner. 

Upon entry to the CALL ACTIVE state from the MO-CALL-SETUP state or MT-CALL-SETUP state, the MS shall 
assume it is not a call owner unless it transitioned to the CALL ACTIVE state as a result of receiving a D-CONNECT 
PDU with the "Call ownership" element set to "A call owner". 



ETSI 



252 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



In any non-IDLE state, if a MS which is a call owner receives an individually addressed or group addressed D-INFO 
PDU with the "Call ownership" element set to "Not a call owner", the MS shall no longer be a call owner. In any 
non-IDLE state, if a MS which is not a call owner receives an individually addressed or group addressed D-INFO PDU 
with the "Call ownership" element set to "A call owner", the MS shall become a call owner. 

1 4.5.3 Traffic channel assignment procedures 
14.5.3.1 SwMI related procedures 

This clause describes procedures which shall be applicable only to the SwMI. Depending on the traffic case, alternative 
methods for traffic channel assignment can be used as presented in table 14.1. 

Table 14.1 : Traffic channel assignment 



TRAFFIC CASE 


Early traffic 

cliannel 
assignment 


Medium traffic 

channel 

assignment 


Late traffic 

channel 
assignment 


Message trunked system; 
Individual call; 
On/Off hook signalling; 


Yes 


Yes 


Yes 


Message trunked system; 

Individual call; 

Direct set-up signalling; 


Yes 


No 


Yes 


Transmission trunked system; 
Individual call; 
On/Off hook signalling; 


No 


No 


Yes 


Transmission trunked system; 

Individual call; 

Direct set-up signalling; 


No 


No 


Yes 


Quasi-transmission trunked system; 
Individual call; 
On/Off hook signalling; 


No 


No 


Yes 


Quasi-transmission trunked system; 

Individual call; 

Direct set-up signalling; 


No 


No 


Yes 


Message trunked system; 
Group call; 


Yes 


No 


Yes 


Transmission trunked system; 
Group call; 


No 


No 


Yes 


Quasi-transmission trunked system; 
Group call; 


No 


No 


Yes 



For the called MSs in a group call, the traffic channel assignment should always be given along with the D-SETUP 
PDU. 

The following methods are available for assigning a traffic channel to a call: 

• Early assignment: 

the traffic channels are assigned and indicated to the calling and called MS along with the 
D-CALL PROCEEDING and D-SETUP PDUs respectively (contained in the lower layer part of those 
messages). In this case the calling MS moves immediately to the traffic channel in anticipation of the call 
and should receive CC messages on this channel; 

• Medium assignment: 

the traffic channels are assigned and indicated to the calling MS along with the D-ALERT PDU and are 
indicated to the called MS in a layer 2 acknowledgement to the called MS U-ALERT PDU. In this case 
the calling MS moves to the traffic channel in anticipation of the call and should receive CC messages on 
this channel; 
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Late assignment individual call: 



the traffic channels are not assigned until the called MS sends a U-CONNECT PDU. Upon reception of 
this PDU the traffic channels may be indicated to the calling and called MS along with the D-CONNECT 
and D-CONNECT ACKNOWLEDGE PDUs respectively In this case the calhng MS shall remain 
listening on the control channel until it is told to move to the traffic channel; 

• Late assignment group call: 

the traffic channels are not assigned until appropriate conditions are met. These conditions may be as a 
result of the finite time required to locate group members, or as a result of the call being acknowledged. 
The traffic channel may be indicated to the calling MS along with the D-CONNECT PDU. 

NOTE 1 : When a MS is said to be sent to a traffic channel in the text above, it means that the MS is ordered to go 
to an assigned channel. For early and medium assignment, the assigned channel starts as a FACCH until 
the MS is instructed to switch the U-plane on. For late assignment, the MS may be instructed to switch 
the U-plane on when it moves to the assigned channel. 

NOTE 2: In this edition of the present document, the implications for the MS-related traffic channel assignment 
procedures (refer to clause 14.5.3.2) of the traffic channel assignment type used by the SwMI have not 
been fully considered for the "early" and "medium" channel assignment types. 

14.5.3.2 MS related procedures 
14.5.3.2.1 General procedures 

The MAC layer manages radio channel changes as described in clause 23.5.4. It is possible that the MAC layer may 
receive conflicting channel allocations when the MS is already involved in a service and receives a new service 
indication. Also, the SwMI may re-allocate radio resources so that concurrent services a MS is using are no longer 
utilizing resources which are within the capabilities of the MS e.g. sharing the same radio channel. In those situations, 
the MAC layer needs to ask from the higher layers which channel allocation it will follow so that the preferred service 
continues or replaces the current service. 

The CMCE may receive a "channel change response required" request with any of the following primitives: 

a) MLE-UNITDATA indication 

For this primitive, the channel assignment is associated with a CC PDU; the primitive is derived from a layer 2 
TL-DATA indication primitive or TL-UNITDATA indication primitive, refer to clauses 18.3.5.3.1, 20.3.5.1.4, 
20.3.5.1.9, 22.2.1.1 and 22.2.1.2. 

b) MLE-REPORT indication 

For this primitive, the channel assignment is associated with a layer 2 acknowledgement; the primitive is derived from a 
layer 2 TL-DATA confirm primitive, refer to clauses 18.3.5.3.1, 20.3.5.1.4 and 22.2.1.1. 

c) MLE-CONFIGURE indication 

For this primitive, the channel assignment is associated with neither a CC PDU nor a layer 2 acknowledgement; the 
primitive is derived from a layer 2 TL-REPORT indication primitive, refer to clauses 18.3.5.4, 20.3.5.1.9 and 22.3.5. 

NOTE 0: Though the SwMI does not have to send a CC PDU with a traffic channel assignment, it is recommended 
that the SwMI sends a CC PDU with any channel assignment not sent with a layer 2 acknowledgement in 
order to facilitate routing of the channel assignment to the correct CC instance. It is recommended that the 
SwMI use the D-INFO PDU if it sends a CC PDU solely for the piupose of associating a channel 
assignment with a call. 

If a channel change response is required the CMCE shall send a MLE-CONFIGURE request primitive with the 
"channel change accepted" parameter set to one of the following values (refer to clause 17.3.9): 

• accept; 

• reject; 
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Ignore. 



NOTE 1 : "ignore" is reserved for specific call situations and is not available for other purposes, refer to 
clause 14.5.3.2.3. 

The CC will normally immediately return "accept" when it accepts the service, and "reject" when it does not accept the 
offered service. The CC may need to return "ignore" in response to a group addressed channel allocation, in which case 
the response will be immediate, refer to clause 14.5.3.2.3 for a description of those scenarios in which "ignore is used. 
In group call case the MS may also delay the sending of the MLE-CONFIGURE request primitive for up to time T330. 
For late traffic channel assignment, CC shall not reject the channel allocation whilst accepting the service. 

NOTE 2: How CMCE or CC entity knows which of the offered or existing services it will accept/select or how it 
negotiates with other network layers or user application to find out the preferred service is outside the 
scope of this part of the present document. 

NOTE 3: The MAC actions for "reject" and "ignore" are generally the same except for specific situations, see 
clauses 23.5.4.2.3 and 23.5.4.2.4 for details. 

NOTE 4: Handling of channel allocations may also be affected by the MS being active in a MM procedure, this 
being indicated to CC from MLE via the MLE-BUSY indication primitive, refer to clause 18.3.5.4. The 
exact nature of the interaction between MM/MLE and CC is outside the scope of this part of the present 
document but it is recommended that CC not accept a channel allocation while MM is busy. 

1 4.5.3.2.2 Procedures for acceptance of individually-addressed channel allocation 

As described in clauses 14.5.1.1.1, 14.5.1.1.3 and 14.5.6.5.3, it is optional whether the MS accepts an incoming 
individual call. Therefore, when the MAC receives a channel allocation addressed to it, it refers to the higher layers for 
instruction about whether to accept the channel allocation. 

The lower layers indicate that instruction is required by setting the "channel change response required" parameter to 
"true". This parameter is passed (via LLC, MLE and PC) to CC along with the PDU. If the CC decides to accept the 
channel allocation then it shall return a CONFIGURE request primitive with the parameter "channel change accepted" 
set to "accept". The CC may also decide to reject a channel allocation in which case CC shall use "channel change 
accepted" parameter value "reject". The CC shall decide whether to accept or reject a channel allocation by applying the 
following rules: 

• if the PDU relates to an ongoing call (i.e. if the call identifier in the received PDU is the call identifier of any 
current call that the MS is active in) and if the CC obeys the received PDU then the CC shall accept the 
channel change; 

• if the PDU relates to an ongoing call and if the CC does not obey the received PDU then the CC shall reject 
the channel change; 

• if the PDU relates to a new service and if the CC obeys the received PDU then the CC shall accept the channel 
change; 

• if the PDU relates to a new service and if the CC does not obey the received PDU then the CC shall reject the 
channel change. 

NOTE: The "ignore" value is not used as a response to any individually addressed channel allocation. 

1 4.5.3.2.3 Procedures for acceptance of group-addressed channel allocation 

As described in clause 14.5.2.1.1, it is optional whether the MS accepts an incoming group call. Therefore, when the 
MAC receives a channel allocation addressed to a group that the MS belongs to, it refers to the higher layers for 
instruction about whether to accept the channel allocation. 
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The lower layers indicate that instruction is required by setting the "channel change response required" parameter to 
"true". This parameter is passed (via LLC, MLE and PC) to CC along with the PDU. If the CC decides to accept the 
channel allocation then it shall return a CONFIGURE request primitive with the parameter "channel change accepted" 
set to "accept". The CC may also decide to reject a channel allocation in which case CC shall use "channel change 
accepted" parameter value "reject". The CC shall decide whether to accept, reject or in specific cases ignore a channel 
allocation by applying the following rules: 

• if the PDU is a group addressed D-SETUP PDU then: 

if the MS is not currently attempting to call this group then the CC shall accept the channel change if the 
user application accepts the incoming call using TNCC-SETUP response primitive, refer to clause 
14.5.2.1.1 and 14.5.2. L3 for other actions; 

if the MS is not currently attempting to call this group then the CC shall reject the channel change if the 
user application rejects the incoming call using TNCC-RELEASE request primitive; 

if the MS is currently attempting to call this group, and has not received a REPORT indication primitive 
of successful transmission of the U-SETUP PDU from the lower layers, then: 

■ if it is requesting a "basic service information" compatible with that in the D-SETUP PDU then it 
shall send a CANCEL request primitive to the lower layers to stop transmission of the U-SETUP 
PDU then: 

if cancellation is successful, the MS shall accept the channel change; 

if cancellation is unsuccessful, the MS shall ignore the channel change and shall wait on the 
current channel for further signalUng: a D-CALL PROCEEDING and/or D-CONNECT PDU 
(and/or D-RELEASE PDU). 

■ if it is requesting a "basic service information" not compatible with that in the D-SETUP PDU then 
it shall accept the channel change if the user application accepts the incoming call using 
TNCC-SETUP response primitive, refer to clause 14.5.2.1.3 for other actions; 

■ if it is requesting a "basic service information" not compatible with that in the D-SETUP PDU then 
it shall reject the channel change if the user application rejects the incoming call using 
TNCC-RELEASE request primitive. 

if the MS is attempting to call this group and has received a REPORT indication primitive of successful 
transmission of the USETUP PDU by the LLC but not yet received a call identifier then it shall ignore 
the channel change and shall wait on the current channel for further signalling: a 
D-CALL PROCEEDING and/or D-CONNECT PDU (and/or D-RELEASE PDU); 

if the MS is attempting to call this group and has received D-CALL PROCEEDING PDU and the call 
identifier in the D-SETUP PDU is the same as the call identifier in the D-CALL PROCEEDING PDU 
and the calling party address in the D-SETUP PDU does not contain the MS's own address then the CC 
shall accept the channel change; 

if the MS is attempting to call this group and has received D_CALL PROCEEDING PDU and the call 
identifier in the D-SETUP PDU is the same as the call identifier in the D-CALL PROCEEDING PDU 
and the calling party address in the D-SETUP PDU contains the MS's own address then the CC shall 
ignore the channel change. 

• if the PDU relates to an ongoing call (i.e. if the call identifier in the received PDU is the call identifier of any 
current call that the MS is active in) and if the CC obeys the received PDU then the CC shall accept the 
channel change; 

• if the PDU relates to an ongoing call and if the CC does not obey the received PDU then: 

if the MS is transmitting traffic and the PDU is a group addressed D-TX GRANTED or 
D-TX INTERRUPT PDU then the CC shall ignore the channel change; 

in all other cases the CC shall reject the channel change. 
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14.5.4 SS procedures 

SS sub-entity 



c 



rb route 



ROUTER 



3 




SS1) (SS2) (SS3) (SS4 




C 




SSnn) 



ROUTER 



3 



re_route 
Figure 14.23: Internal view of SS sub-entity 

Figure 14.23 shows the internal architecture of the SS sub-entity. The user application shall communicate with SS 
entities via the rb-route, when the information of the requested service is not incorporated into TNCC-S AP service 
primitives, see clauses 1 1 and 12. All messages to and from PC shall be communicated over the re-route. When a SS 
message is received from the peer entity, it shall be passed via the SS router to the appropriate SS entity. 

Each individual SS entity shall receive and send call related SS messages as facility elements in CC PDUs, or if no 
other call related PDU is available, in a U/D-INFO PDU. The call identifier element shall link the SS facility element to 
the related call. 

If the SS message is not related to any existing call, it shall be conveyed as a facility element in a U/D-FACILITY 
PDU. 

Some SS messages may be sent or received at any stage of a call, after the call during SS-CC retention time and when 
no call exists. 



14.5.5 SDS procedures 



The SDS procedures handled by the SDS sub-entity shall be applicable for the MS side. The procedures relating to the 
SwMI are outside the scope of the present document. 

In the SDS protocol there is no relationship defined between SDS messages using different transmission directions and 
the SDS sub-entity shall be able to handle colliding messages, e.g. shall receive messages to be sent to the peer entity 
and shall deliver received messages from the peer entity at the same time. 

14.5.5.1 Incoming short data message 

On reception of D-STATUS or D-SDS-DATA PDUs the SDS sub-entity shall inform the user application with a 
TNSDS-STATUS indication primitive containing the pre-coded status or with a TNSDS-UNITDATA indication 
primitive containing user defined data, respectively. 

14.5.5.2 Outgoing short data messages 

A user application initiates the SDS message transfer by issuing either a TNSDS-STATUS request primitive or a 
TNSDS-UNITDATA request primitive. The SDS sub-entity shall select an appropriate PDU priority based on the 
requested access priority value as described in clause 14.5.6.2. 

Upon reception of a TNSDS-STATUS or a TNSDS-UNITDATA request primitive the SDS sub-entity shall send the 
corresponding U-STATUS or U-SDS-DATA PDU respectively. The SDS sub-entity may suggest the use of an 
advanced link by using the U-SDS DATA primitive's link identifier parameter. 

NOTE: The advanced link may use less air interface resource than the basic link in certain conditions when 

transmitting a long PDU in an imperfect channel. It may be desirable to use an advanced link when the 
U-SDS-DATA PDU cannot be carried by the basic link within a MAC-ACCESS PDU plus two or three 
full slots, particularly where the MS may be using a 25 kHz QAM channel. 
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The SDS sub-entity shall not accept farther short data request primitives from the user application before a REPORT 
indication primitive indicating successful transmission of the PDU has been received. The received report shall be 
forwarded to the user application in a TNSDS-REPORT indication primitive. 

If the SDS entity receives a REPORT indication primitive informing that the PDU transmission was unsuccessful, the 
SDS sub-entity shall inform the user application using a TNSDS-REPORT indication primitive with parameter "failure" 
and the SDS sub-entity may continue to accept new SDS service requests. 

14.5.6 PC procedures 

This clause contains various protocol elements which are common to one or more sub-entities within the CMCE. The 
description does not define or limit implementations to be inside the PC sub-entity. 



14.5.6.1 



Access to the communication resources 



When the MS is powered up all the CMCE sub-entities except the PC sub-entity shall start in state IDLE. The PC sub- 
entity shall start in state CLOSED. When the PC sub-entity receives a MLE-OPEN indication primitive, the PC sub- 
entity shall change state to OPEN and inform other sub-entities with an OPEN indication primitive. When the PC is in 
state CLOSED the other sub-entities shall not send any PDUs. When the PC receives a MLE-CLOSE indication 
primitive, the PC sub-entity shall change state to CLOSED and shall inform the other sub-entities with a CLOSE 
indication primitive. 

MLE-BREAK indication primitive, REOPEN indication primitive, RESTORE confirm primitive and RESUME 
indication primitive shall not change the state of the PC, but PC shall pass those to other sub-entities as defined in 
clause 14.2.6. 

14.5.6.2 Access priority handling 

When any CMCE sub-entity receives an access priority value in a TNCC, TNSS or TNSDS primitive, the sub-entity 
shall set the PDU priority value according to the access priority value. If the corresponding PDU priority is not defined 
by other means, then the sub-entity shall use default values as defined in table 14.2. 

Table 14.2: Low/high/emergency PDU priority default values 



PDU 


PDU priority 


Remark 


U-ALERT 


2/4/7 


Stealing repeats flag not set 


U-CALL-RESTORE 


5 


Stealing repeats flag not set 


U-CONNECT 


2/4/7 


stealing repeats flag not set 


U-DISCONNECT 


6 


Immediate stealing and Stealing repeats flag set 


U-INFO 


2/4/7 


Stealing repeats flag not set 


U-RELEASE 


6 


Stealing repeats flag not set 


U-SETUP 


0/4/7 


Stealing repeats flag not set 


U-STATUS 


1/4/7 


Stealing repeats flag not set 


U-SDS DATA 


1/4/7 


Stealing repeats flag not set 


U-TX CEASED 


6 


Immediate stealing and Stealing repeats flag set 


U-TX DEMAND 


2/4/7 


Stealing repeats flag not set 



For PDUs other than U-TX CEASED and U-DISCONNECT, the CC sub-entity shall set the stealing permission 
parameter according to the following rules: 

• if "traffic stealing = steal traffic" and "access priority = emergency" in the service access primitive, the stealing 
permission parameter shall be set to "steal immediately"; 

• if "traffic stealing = steal traffic" and access priority is not equal to "emergency" in the service access 
primitive, the stealing permission parameter shall be set to "steal when convenient"; 

• otherwise the stealing permission parameter shall be set to "stealing not required". 
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14.5.6.2.1 Cancel 

The cancel procedures may be implemented in an MS and if used the following shall apply: 

• the MLE-CANCEL request primitive can minimize the risk of adding extra load to the air interface, e.g. when 
a user application requests a call set-up and the request is buffered by the lower layers waiting for allowance to 
make a random access attempt, which in the case of a low priority call and high system load can take a 
considerable amount of time. If the user application, during this waiting period, changes its decision and wants 
to disconnect the call, the application shall send a TNCC-RELEASE request primitive to the CC sub-entity. 
The CC sub-entity shall know the status of the transmission from the REPORT indication primitives received 
from the lower layers; 

• when any sub-entity wishes to stop transmission of a PDU it may use cancel procedure with the limitations 
defined below. The cancel process shall be controlled by REPORT indication primitives from lower layers; 

• incoming MLE-REPORT indication primitives should indicate the following events: 

a PDU has been stored by the DLL ready for transmission. At this stage the transmission may be 
cancelled using a CANCEL request primitive and no information will be sent over the air interface; 

the first transmission of whole PDU. The BS may have received the PDU, but MS has not yet received 
an acknowledgement. At this stage the layer 2 process may be stopped using a CANCEL request 
primitive, but the sending sub-entity cannot rely on the cancellation and may receive a response to the 
sent PDU; 

the transfer of a PDU has failed in layer 2. Cancellation is no longer possible, but the BS may have 
received the PDU correctly and the sending sub-entity may receive a response to the sent PDU; 

a PDU has been successfully transmitted by layer 2. Cancellation is no longer possible. 

14.5.6.3 CMCE PDU exchange 

The PC shall forward PDUs from the other CMCE sub-entities to MLE using a MLE-UNITDATA request primitive 
without modifying any parameters supplied with the PDU. However the U-CALL RESTORE PDU shall use 
a MLE-RESTORE request primitive instead of the MLE-UNITDATA request primitive. 

The PC shall forward the SDU contained in a received MLE-UNITDATA indication primitive to the corresponding 
sub-entity as defined by the PDU type element without modifying any parameters. The D-CALL RESTORE PDU 
should be received in a MLE-RESTORE confirm primitive instead of the MLE-UNITDATA indication primitive. 

14.5.6.3.1 Choice of layer 2 service 

When sending the following PDUs, the layer 2 service parameter shall be set to "acknowledged response": 

• U-ALERT PDU; 

• U-CONNECT PDU for direct call set-up; 

• U-DISCONNECT PDU when sent as a response to a D-SETUP PDU; 

• U-RELEASE. 

For other uplink PDUs, the PC should set the layer 2 service parameter to "acknowledged request". 

14.5.6.4 Control Information exchange 

CMCE sub-entities exchange local control information with the PC using service primitives. 

The PC shall forward service primitives from other CMCE sub-entities to the MLE using MLE service primitives as 
defined in clause 17.3.4 without any modification of the parameters. 

The PC shall forward service primitives from MLE, as defined in clause 17.3.4 to the relevant sub-entity or sub-entities 
without any modification of parameters. 
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The primitive names and parameters between the PC and the other sub-entities are same as the primitive names at the 
MLE-SAP except that the "MLE-" is not present. 

The CC protocol cannot support overlapping call set-up signalling within the window where the CC awaits a call 
identifier from the SwMI after a U-SETUP PDU is issued. A method to prevent concurrent call set-up attempt during 
the window is described as follows: 

• when a CC instance initiates a call set-up, it shall inform PC that a call set-up has been initiated, and the PC 
shall inform other CC instances that currently no more call set-up attempts are possible; 

• when the CC instance either receives a call identifier for the new call or discards the call set-up, it shall inform 
completion of call set-up to the PC, and the PC shall forward that information to the other CC instances. 

This method enables correct mapping between the call identifier and the appropriate CC instance. 

14.5.6.5 PC protocol error conditions 

14.5.6.5.1 PDU type error 

When a PDU is received with a PDU type not recognizable, the MS may, if the PDU is individually addressed, send a 
CMCE FUNCTION NOT SUPPORTED PDU, refer to clause 14.7.3.2. The MS shall ignore the unrecognizable PDU. 

If the MS receives an individually addressed CMCE PDU with a valid PDU type but some unrecognized element or 
element values prevent the MS from interpreting the PDU correctly, the MS may send a CMCE FUNCTION NOT 
SUPPORTED PDU. 

The behaviour of the requesting party when receiving a CMCE FUNCTION NOT SUPPORTED PDU is outside the 
scope of the present document. 

14.5.6.5.2 Invalid call identifier 

If a MS receives any individually addressed down link PDU except D-SETUP and D-RELEASE PDUs specifying a call 
identifier element which is not recognized as relating to a call for which a call identifier exists, the PC shall send a 
U-DISCONNECT PDU with the received invalid call identifier and with the cause "Invalid call identifier". 

In all other cases, no action shall be taken by PC. 

14.5.6.5.3 MS busy 

If the MS is engaged in another service or services e.g. circuit mode call or packet data service, and cannot support 
more concurrent calls and the user application, when it receives an individually addressed D-SETUP PDU, does not 
release any calls and does not reject the incoming call (refer to clause 14.5.1.1.5), the MS shall send a 
U-DISCONNECT PDU back to the SwMI with cause "Called party busy". 

14.5.6.6 Temporary Disablement 

When the PC receives a MLE-DISABLE indication primitive, CMCE shall cease all communication with MLE apart 
from: 

• reception of MLE-CLOSE indication, MLE-OPEN indication and MLE-ENABLE indication primitives: 

• if the MLE-DISABLE indication primitive included LIP as a permitted service: 

primitives transporting LIP protocol via SDS PDUs; 

• if the MLE-DISABLE indication primitive included ambience listening as a permitted service: 

primitives transporting signalling related to ambience listening. 

The method by which CMCE permits only these services while preventing all others is outside the scope of the present 
document. 

When the PC receives a MLE-ENABLE indication primitive, CMCE shall resume full communication with MLE. 
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PC shall sustain its temporary disablement condition through power cycles, through loss and regain of radio resources, 
and through switching to DMO and back. 

NOTE: An MS that is temporarily disabled during V+D operation remains disabled during DMO operation, but 
the method by which the MS achieves this is outside the scope of the present document. 

14.5.7 Subscriber class 

Where the CMCE receives a MLE-INFO indication primitive which indicates that the subscriber class associated with 
the ITSI is not valid on a cell the CMCE shall filter service requests until the subscriber class becomes valid, or a new 
cell is selected where the subscriber class is valid, this being indicated from MLE to CMCE via the MLE-INFO 
indication primitive. In addition, the CMCE shall only generate PDUs which relate to existing circuit mode calls. The 
CMCE shall not generate PDUs relating to new calls, unless they have a message priority of 7, indicating an emergency 
call. If an MS subscriber class is not supported by the current serving cell, the MS shall only be allowed to register on 
that cell, initiate emergency calls or signalling, and receive incoming calls/signalling on that cell. 

14.5.8 Activity handling 

PC shall send an MLE- ACTIVITY request primitive to the MLE when it receives an ACTIVITY request primitive from 
a CC entity. 
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14.6 Protocol timers 

Table 14.3 lists the protocol timers and the information associated with them. 

Table 14.3: Timers 



Timer 


Timer 


Call state 


Cause for start 


Normally terminated 


Action when 


l/C 


0/G 


No. 


value 








timer expires 


side 


side 


T301 


IVIaximum 


MT-CALL- 


On the sending of 


On receipt of 


Disconnect as 


M 


- 


(see 


30 s 


Set-up 


U-CONNECT, 


D-CONNECT ACK, 


specified in clause 






note 1 ) 






On receipt of 
D-INFO 


D-DISCONNECT, 
D-RELEASE, 
Report (failed) ind 


14.5.1.3.4 a) 






T302 


IVIax. 60 s 


MO-CALL- 


On receipt of D-CALL 


On receipt of 


Disconnect as 


- 


M 


(see 




Set-up 


PROCEEDING, 


D-CONNECT, 


specified in 






note 2) 






D-ALERT or D-INFO 


D-SETUP, 
D-DISCONNECT, 
D-RELEASE, 
Report (failed) ind 


clauses 

14.5.1.3.4 b) and 

14.5.2.3.5 a) 






T303 


60s 


MO-CALL- 


On the sending of 


On receipt of 


Disconnect as 


- 


M 






Set-up 


U-SETUP 


D-CALL 
PROCEEDING, 
D-ALERT, 
D-CONNECT, 
D-RELEASE, 
Report (failed) ind 
On transmission of 
U-DISCONNECT 


specified in 
clauses 14.5.1.3.4 
c) and 
14.5.2.3.5 b) 






T306 


Min 4 sec 


Break 


On sending of 


On receipt of 


Disconnect as 


M 


M 




IVIax 6 sec 




U-CALL RESTORE (Pt to 
Pt calls only) 


D-CALL RESTORE, 
Reopen ind 


specified in clause 
14.5.1.3.4 e) 






T307 


Min 2 sec 


Break 


On sending of U-CALL 


Receipt of 


Disconnect as 


M 


M 




IVIax 8 sec 




RESTORE (Pt to MtPt 
calls only) 


D-CALL RESTORE, 
Reopen ind 


specified in clause 
14.5.2.3.5 c) 






T308 


Max. 10 


Any State 


On transmission of 


Receipt of 


Disconnect as 


M 


M 


(see 


sec 




U-DISCONNECT 


D-RELEASE, 


specified in 






note 3) 








Report (failed) ind 


clauses 

14.5.1.3.4 f) and 

14.5.2.3.5 d) 






T310 


Min 30 sec 


Call Active 


On receipt of 


On receipt of 


Disconnect as 


M 


M 


(see 


No Max. 




D-CONNECT, 


D-RELEASE, 


specified in 






note 4) 






D-CONNECT 

ACKNOWLEDGE, 

D-TX CONTINUE, 

D-SETUP (Pt to MtPt 

calls only), 

D-INFO, 

D-CALL RESTORE 


D-TX WAIT, 
Report (failed) ind 
On transmission 
of U-DISCONNECT, 
U-RELEASE 


clauses 

14.5.1.3.4 g) and 

14.5.2.3.5 e) 






T311 


Max. 300 


Call Active 


On receipt of 


On transmission 


Forced Ceased 


M 


M 




sec 


TX 


D-TX GRANTED 

(transmit), 

D-TX CONTINUE 

(continue) 

(see note 5), 

D-CONNECT (transmit), 

D-CONNECT 

ACKNOWLEDGE 

(transmit) 


of U-TX CEASED, 
U-DISCONNECT 
On receipt of 
D-TX INTERRUPT, 
D-RELEASE, 
D-TX WAIT, 
D-TX CONTINUE 
(not continue). 
Report (failed) ind 


Transmission. 
Transmission of 
U-TX CEASED 
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Timer 
No. 


Timer 
value 


Call state 


Cause for start 


Normally terminated 


Action when 
timer expires 


l/C 
side 


0/G 
side 


T330 


10 sec 


MT-CALL- 
Set-up 


On receipt of a channel 
change response 
required set to "yes" 


On sending 
corresponding 
channel change 
accepted set to any 
value 


CC can no longer 
accept the 
channel change 


M 




NOTE 1 : This timer is started with a fixed duration of 30 s on the sending of U-CONNECT; the timer may be 
started again on receipt of D-INFO (with the duration specified in the D-INFO). 

NOTE 2: This timer may be started again during the call on receipt of D-INFO. 

NOTE 3: This timer may have (zero) duration in which case the MS does not wait for D-RELEASE after having 
sent U-DISCONNECT. 

NOTE 4: This timer may be started again during the call on receipt of D-INFO or D-CALL RESTORE. 

NOTE 5: The timer is started as a result of receiving D-TX CONTINUE (continue) only if the IVIS had transmit 
permission when it received D-TX WAIT. 



14.7 PDU descriptions 



The PDUs detailed within this clause shall be visible at the Um reference point. 

Refer to annex E for PDU encoding rules and examples. 

Various supplementary services use the notification information element in some PDUs, refer to EN 300 392-9 [9]. 

The information contained in the following PDU description tables corresponds to the following key: 

Length: length of the element in bits; 

Type: element type (1, 2 or 3) as defined above; 

Owner: sub-entity responsible for (or owner of) the element data; 

C/O/M: conditional/optional/mandatory information in the PDU; 

Remark: comment. 
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14.7.1 PDU description tables - downlinl< 



14.7.1.1 



D-ALERT 



Message: 



D-ALERT 



Response to: U-SETUP 

Response expected: 



Short description: 



Tiiis PDU shall be an information to the originating MS that the call is proceeding 
and the connecting party has been alerted. 

Table 14.4: D-ALERT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


D-ALERT 


Call identifier 


14 




cc 


M 




Call time-out, set-up phase 


3 




CC 


M 




Reserved 


1 




cc 


M 


See note 1 


Simplex/duplex selection 


1 




cc 


M 




Call queued 


1 




cc 


M 




Basic service information 


8 


2 


cc 





See note 2 


Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







Proprietary 




3 


- 







NOTE 1 : This information element is not used in this edition of the present document and its value shall be set to 
"1 " (equivalent to "Hook on/Hook off signalling" for backwards compatibility with edition 1 of the present 
document - refer to table 1 4.62). 

NOTE 2: If different from requested. 



14.7.1.2 



D-CALL PROCEEDING 



Message: 



D-CALL PROCEEDING 



Response to: U-SETUP 

Response expected: 



Short description: 



This PDU shall be the acknowledgement from the infrastructure to call set-up request 
indicating that the call is proceeding. 

Table 14.5: D-CALL PROCEEDING PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


D-CALL PROCEEDING 


Call identifier 


14 




CC 


M 




Call time-out, set-up phase 


3 




cc 


M 




Hook method selection 


1 




cc 


M 




Simplex/duplex selection 


1 




cc 


M 




Basic service information 


8 


2 


cc 





See note 


Call status 


3 


2 


cc 







Notification indicator 


6 


2 


SS 







Facility 




3 


ss 







Proprietary 




3 


- 







NOTE: If different from requested. 
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14.7.1.3 D-CALL RESTORE 

• Message: D-CALL RESTORE 

• Response to: U-CALL RESTORE 

• Response expected: 

• Short description: 



This PDU shall indicate to the MS that a call has been restored after a temporary break 
of the call. 

Table 14.6: D-CALL RESTORE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


D-CALL RESTORE 


Call identifier 


14 




CC 


M 




Transmission grant 


2 




CC 


M 




Transmission request permission 


1 




CC 


M 




Reset call time-out timer (T310) 


1 




CC 


M 




New call identifier 


14 


2 


CC 







Call time-out 


4 


2 


CC 







Call status 


3 


2 


CC 







Modify 


9 


2 


CC 







Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







Temporary address 




3 


CC 







DIVI-MS address 




3 


CC 







Proprietary 




3 


- 








14.7.1.4 



D-CONNECT 



Message: 



D-CONNECT 



Response to: U-SETUP 

Response expected: 

Short description: This PDU shall be the order to the calling MS to through-connect. 

Table 14.7: D-CONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


D-CONNECT 


Call identifier 


14 




CC 


M 




Call time-out 


4 




CC 


M 




Hook method selection 


1 




CC 


M 




Simplex/duplex selection 


1 




CC 


M 




Transmission grant 


2 




CC 


M 




Transmission request permission 


1 




CC 


M 




Call ownership 


1 




CC 


M 




Call priority 


4 


2 


CC 







Basic service information 


8 


2 


CC 





See note 


Temporary address 


24 


2 


CC 







Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







Proprietary 




3 


- 







NOTE: If different from requested. 
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14.7.1.5 D-CONNECT ACKNOWLEDGE 

• Message: D-CONNECT ACKNOWLEDGE 

• Response to: U-CONNECT 

• Response expected: 

• Short description: This PDU shall be the order to the called MS to through-connect. 

Table 14.8: D-CONNECT ACKNOWLEDGE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


D-CONNECT 
ACKNOWLEDGE 


Call identifier 


14 


1 


cc 


M 




Call time-out 


4 


1 


CC 


M 




Transmission grant 


2 


1 


cc 


M 




Transmission request permission 


1 


1 


cc 


M 




Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







Proprietary 




3 


- 








14.7.1.6 D-DISCONNECT 

• Message: D-DISCONNECT 

• Response to: 

• Response expected: U-RELEASE 

• Short description: This PDU shall be the disconnect request message sent from the infrastructure to 

the MS. 

Table 14.9: D-DISCONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


D-DISCONNECT 


Call identifier 


14 


1 


CC 


M 




Disconnect cause 


5 


1 


cc 


M 




Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







Proprietary 




3 


- 








14.7.1.7 D-FACILITY 

• Message: D-FACILITY 

• Response to: 

• Response expected: 

• Short description: This PDU shall be used to send call unrelated SS information. 

Table 14.10: D-FACILITY PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SS 


M 


D-FACILITY, See note 


NOTE: Contents of this PDU shall be defined by SS protocols. 
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14.7.1.8 



D-INFO 



Message: 



D-INFO 



• Response to: 

• Response expected: 

• Short description: This PDU shall be the general information message to the MS. 

Table 14.11: D-INFO PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


D-INFO 


Call identifier 


14 


1 


CC 


M 


See note 1 


Reset call time-out timer (T31 0) 


1 


1 


CC 


M 




Poll request 


1 


1 


CC 


M 


See note 2 


New call identifier 


14 


2 


CC 







Call time-out 


4 


2 


CC 







Call time-out set-up phase (T301 , T302) 


3 


2 


CC 







Call ownership 


1 


2 


CC 







IVIodify 


9 


2 


CC 







Call status 


3 


2 


CC 







Temporary address 


24 


2 


CC 







Notification indicator 


6 


2 


ss 







Poll response percentage 


6 


2 


CC 





See note 3 


Poll response number 


6 


2 


CC 





See note 3 


DTMF 




3 


CC 







Facility 




3 


ss 







Poll response addresses 




3 


CC 





See note 3 


Proprietary 




3 


- 







NOTE 1 : If the message is sent connectionless the call identifier shall be the dummy call identifier. 
NOTE 2: Shall be valid for acknowledged group call only. For other types of calls it shall be set = 0. 
NOTE 3: Shall be valid for acknowledged group call only. 



14.7.1.9 D-RELEASE 

• Message: D-RELEASE 

• Response to: 

• Response expected: 

• Short description: 



-/U-DISCONNECT 



This PDU shall be a message from the infrastructure to the MS to inform that 
the connection has been released. 

Table 14.12: D-RELEASE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


D-RELEASE 


Call identifier 


14 


1 


CC 


M 




Disconnect cause 


5 


1 


CC 


M 




Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







Proprietary 




3 


- 
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14.7.1.10 D-SDS-DATA 



Message: 



D-SDS-DATA 



• Response to: 

• Response expected: 

• Short description: This PDU shall be for receiving user defined SDS data. 

Table 14.13: D-SDS-DATA PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SDS 


M 


D-SDS-DATA 


Calling party type identifier 


2 


1 


SDS 


M 




Calling party address SSI 


24 




SDS 


C 


See note 1 


Calling party extension 


24 




SDS 


C 


See note 1 


Short data type identifier 


2 


1 


SDS 


M 




User defined data-1 


16 




SDS 


C 


See note 2 


User defined data-2 


32 




SDS 


C 


See note 2 


User defined data-3 


64 




SDS 


c 


See note 2 


Length indicator 


11 




SDS 


c 


See note 2 


User defined data-4 






SDS 


c 


See note 2 


External subscriber number 




3 


SDS 







DIVI-MS address 




3 


CC 







NOTE 1 : Shall be conditional on the value of Calling Party Type Identifier (CPTI): 

- CPTI = 1; Calling Party SSI; 

- CPTI = 2; Calling Party SSI + Calling Party Extension. 

NOTE 2: Shall be conditional on the value of Short Data Type Identifier (SDTI): 

- SDTI = 0; User Defined Data-1 ; 

- SDTI = 1 ; User Defined Data-2; 

- SDTI = 2; User Defined Data-3; 

- SDTI = 3; Length Indicator + User Defined Data-4. 



14.7.1.11 D-STATUS 



Message: 



D-STATUS 



• Response to: 

• Response expected: 

• Short description: This PDU shall be the PDU for receiving a pre-coded status message. 

Table 14.14: D-STATUS PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SDS 


M 


D-STATUS 


Calling party type identifier 


2 


1 


SDS 


M 




Calling party address SSI 


24 




SDS 


C 


See note 


Calling party extension 


24 




SDS 


C 


See note 


Pre-coded status 


16 


1 


SDS 


M 




External subscriber number 




3 


SDS 







DIVI-MS address 




3 


CC 







NOTE: Shall be conditional on the value of Calling Party Type Identifier (CPTI): 

- CPTI = 1; Calling Party SSI; 

- CPTI = 2; Calling Party SSI + Calling Party Extension. 
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14.7.1.12 D-SETUP 

• Message: D-SETUP 

• Response to: 

• Response expected: U-ALERT/U-CONNECT/- 

• Short description: This PDU shall be the call set-up message sent to the called MS. 

Table 14.15: D-SETUP PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


D-SETUP 


Call identifier 


14 




cc 


M 




Call time-out 


4 




CC 


M 




Hook method selection 


1 




cc 


M 




Simplex/duplex selection 


1 




cc 


M 




Basic service information 


8 




cc 


M 




Transmission grant 


2 




cc 


M 




Transmission request permission 


1 




cc 


M 




Call priority 


4 




ss 


M 


See note 1 


Notification indicator 


6 


2 


ss 







Temporary address 


24 


2 


cc 







Calling party type identifier 


2 


2 


cc 





See note 2 


Calling party address SSI 


24 




cc 


c 


See note 3 


Calling party extension 


24 




cc 


c 


See note 3 


External subscriber number 




3 


cc 







Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 







NOTE 1 : This information element is used by SS-PC, refer to EN 300 392-1 2-1 [1 5] and SS-PPC and 

EN 300 392-12-16 [16]. 
NOTE 2: For resolution of possible Facility (Talking Party ldentifier)/Calling party Identifier conflicts, refer to 

EN 300 392-1 2-3 [1 2], clause 5.2.1 .5 and EN 300 392-1 2-1 [1 1 ], clause 4.3.5. 
NOTE 3: Shall be conditional on the value of Calling Party Type Identifier (CPTI): 

- CPTI = 1; Calling Party SSI; 

- CPTI = 2; Calling Party SSI + Calling Party Extension. 



14.7.1.13 D-TX CEASED 

• Message: D-TX CEASED 

• Response to: U-TX CEASED 

• Response expected: 

• Short description: This PDU shall be the PDU from the SwMI to all MS within a call that a transmission 

has ceased. 

Table 14.16: D-TX CEASED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


D-TX CEASED 


Call identifier 


14 


1 


CC 


M 




Transmission request permission 


1 


1 


cc 


M 




Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 
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14.7.1.14 D-TX CONTINUE 



Message: 
Response to: 
Response expected: 
Short description: 



D-TX CONTINUE 



This PDU shall be the information from the SwMI to the MS that the interruption 
of the call has ceased. 

Table 14.17: D-TX CONTINUE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


D-TX CONTINUE 


Call identifier 


14 


1 


cc 


M 




Continue 


1 


1 


CC 


M 




Transmission request permission 


1 


1 


cc 


M 




Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 








14.7.1.15 D-TX GRANTED 



Message: 



D-TX GRANTED 



Response to: U-TX DEMAND 

Response expected: 



Short description: 



This PDU shall inform the MS concerned with a call that permission to transmit has 
been granted by the SwMI to a MS, and to inform that MS that it has been granted 
permission to transmit. This PDU shall also inform a MS that its request to transmit has 
been rejected or queued. 

Table 14.18: D-TX GRANTED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


D-TX GRANTED 


Call identifier 


14 




CC 


M 




Transmission grant 


2 




cc 


M 




Transmission request permission 


1 




cc 


M 




Encryption control 


1 




cc 


M 




Reserved 


1 




cc 


M 


See note 1 


Notification indicator 


6 


2 


ss 







Transmitting party type identifier 


2 


2 


cc 







Transmitting party address SSI 


24 




cc 


c 


See note 2 


Transmitting party extension 


24 




cc 


c 


See note 2 


External subscriber number 




3 


cc 







Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 







NOTE 1 : This information element is not used in this version of the present document and its value shall be set 

to "0". 
NOTE 2: Shall be conditional on the value of Transmitting Party Type Identifier (TPTI): 

- TPTI = 1 ; Transmitting Party SSI; 

- TPTI = 2; Transmitting Party SSI + Transmitting Party Extension. 
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14.7.1.16 D-TX INTERRUPT 

• Message: D-TX INTERRUPT 

• Response to: 

• Response expected: 



Short description: 



This PDU shall be a message from the SwMI indicating that a permission to transmit 
has been withdrawn. 

Table 14.19: D-TX INTERRUPT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


D-TX INTERRUPT 


Call identifier 


14 




cc 


M 




Transmission grant 


2 




CC 


M 




Transmission request permission 


1 




cc 


M 




Encryption control 


1 




cc 


M 




Reserved 


1 




cc 


M 


See note 1 


Notification indicator 


6 


2 


ss 







Transmitting party type identifier 


2 


2 


cc 







Transmitting party address SSI 


24 




cc 


c 


See note 2 


Transmitting party extension 


24 




cc 


c 


See note 2 


External subscriber number 




3 


cc 







Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 







NOTE 1 : This information element is not used in this version of the present document and its value shall be set 

to "0". 
NOTE 2: Shall be conditional on the value of Transmitting Party Type Identifier (TPTI): 

- TPTI = 1 ; Transmitting Party SSI; 

- TPTI = 2; Transmitting Party SSI + Transmitting Party Extension. 



14.7.1.17 D-TX WAIT 

• Message: D-TX WAIT 

• Response to: U-TX DEMAND 

• Response expected: 

• Short description: This PDU shall be a message from the SwMI that the call is being interrupted. 

Table 14.20: D-TX WAIT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


D-TX WAIT 


Call identifier 


14 


1 


CC 


M 




Transmission request permission 


1 


1 


cc 


M 




Notification indicator 


6 


2 


ss 







Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 
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14.7.2 PDU description tables - uplinl< 

14.7.2.1 U-ALERT 

• Message: U-ALERT 

• Response to: D-SETUP 

• Response expected: 

• Short description: This PDU shall be a acknowledgement from the called MS that the called user 

has been alerted. 

Table 14.21: U-ALERT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


U-ALERT 


Call identifier 


14 


1 


cc 


M 




Reserved 


1 


1 


CC 


M 


See note 


Simplex/duplex selection 


1 


1 


cc 


M 




Basic service information 


8 


2 


cc 







Facility 




3 


ss 







Proprietary 




3 


- 







NOTE: This information element is not used in this edition of the present document and its value shall be set to 
"1 " (equivalent to "Hook on/Hook off signalling" for backwards compatibility with edition 1 of the present 
document - refer to table 1 4.62). 



14.7.2.2 



U-CALL RESTORE 



Message: 



U-CALL RESTORE 



Response to: 

Response expected: D-CALL RESTORE 



Short description: 



This PDU shall be the order from the MS for restoration of a specific call after 
a temporary break of the call. 

Table 14.22: U-CALL RESTORE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


U-CALL RESTORE 


Call identifier 


14 


1 


CC 


M 




Request to transmit/send data 


1 


1 


cc 


M 




Other party type identifier 


2 


1 


cc 


M 




Other party short number address 


8 




cc 


c 


See notes 1 and 2 


Other party SSI 


24 




cc 


c 


See note 1 


Other party extension 


24 




cc 


c 


See note 1 


Basic service information 


8 


2 


cc 


M 


See note 3 


Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 







NOTE 1 : Shall be conditional on the value of Called Party Type Identifier (CPTI): 

- CPTI = 0; Called Party SNA; 

- CPTI = 1; Called Party SSI; 

- CPTI = 2; Called Party SSI + Called Party Extension. 

NOTE 2: A use of SNA in call restoration is strongly discouraged as all other call maintenance signalling uses 

SSI and the SS-SNA may not be supported in all networks. 
NOTE 3: Although the coding of this information element is of type 2 the element is mandatory. The information 

element informs the new cell of the basic service of the current call in progress. 
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14.7.2.3 U-CONNECT 

• Message: U-CONNECT 

• Response to: D-SETUP 

• Response expected: D-CONNECT ACKNOWLEDGE 

• Short description: This PDU shall be the acknowledgement to the SwMI that the called MS is ready 

for through-connection. 

Table 14.23: U-CONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


U-CONNECT 


Call identifier 


14 


1 


cc 


M 




Hook method selection 


1 


1 


CC 


M 




Simplex/duplex selection 


1 


1 


cc 


M 




Basic service information 


8 


2 


cc 







Facility 




3 


ss 







Proprietary 




3 


- 








14.7.2.4 U-DISCONNECT 

• Message: U-DISCONNECT 

• Response to: 

• Response expected: D-DISCONNECT/D-RELEASE 

• Short description: This PDU shall be the MS request to the SwMI to disconnect a call. 

Table 14.24: U-DISCONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


U-DISCONNECT 


Call identifier 


14 


1 


CC 


M 




Disconnect cause 


5 


1 


cc 


M 




Facility 




3 


ss 







Proprietary 




3 


- 








14.7.2.5 U-FACILITY 

• Message: U-FACILITY 

• Response to: 

• Response expected: 

• Short description: This PDU shall be used to send call unrelated SS information. 

Table 14.25: U-FACILITY PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SS 


M 


U-FACILITY, See note 


NOTE: Contents of this PDU shall be defined by SS protocols. 
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14.7.2.6 



U-INFO 



Message: 



U-INFO 



• Response to: 

• Response expected: 

• Short description: This PDU shall be the general information message from the MS. 

Table 14.26: U-INFO PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


U-INFO 


Call identifier 


14 


1 


cc 


M 


See note 1 


Poll response 


1 


1 


CC 


M 


See note 2 


IVlodify 


9 


2 


cc 







DTMF 




3 


cc 







Facility 




3 


ss 







Proprietary 




3 


- 







NOTE 1 : If the message is sent connectionless then the call identifier shall be equal to the dummy call identifier. 
NOTE 2: Shall be valid for acknowledged group call only. For other types of call it shall be set equal to zero. 



14.7.2.7 



U-STATUS 



Message: 



U-STATUS 



• Response to: 

• Response expected: 

• Short description: This PDU shall be used for sending a pre-coded status message. 

Table 14.27: U-STATUS PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SDS 


M 


U-STATUS 


Area selection 


4 


1 


SS 


M 


See note 1 


Called party type identifier 


2 


1 


SDS 


M 


Short/SSI/TSI 


Called party short number address 


8 




SDS 


C 


See note 2 


Called party SSI 


24 




SDS 


C 


See note 2 


Called party extension 


24 




SDS 


C 


See note 2 


Pre-coded status 


16 


1 


SDS 


M 




External subscriber number 




3 


SDS 







DIVI-MS address 




3 


CC 







NOTE 1 : This information element is used by SS-AS, refer to EN 300 392-12-8 [14]. 
NOTE 2: Shall be conditional on the value of Called Party Type Identifier (CPTI): 

- CPTI = 0; Called Party SNA; refer to ETS 300 392-12-7 [13]; 

- CPTI = 1; Called Party SSI; 

- CPTI = 2; Called Party SSI + Called Party Extension. 
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14.7.2.8 



U-SDS-DATA 



Message: 



U-SDS-DATA 



• Response to: 

• Response expected: 

• Short description: This PDU shall be for sending user defined SDS data. 

Table 14.28: U-SDS-DATA PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SDS 


IVI 


U-SDS-DATA 


Area selection 


4 


1 


SS 


M 


See note 1 


Called party type identifier 


2 


1 


SDS 


M 


Short/SSI/TSI 


Called party short number address 


8 




SDS 


C 


See note 2 


Called party SSI 


24 




SDS 


c 


See note 2 


Called party extension 


24 




SDS 


c 


See note 2 


Short data type identifier 


2 


1 


SDS 


M 


See note 4 


User defined data-1 


16 




SDS 


c 


See notes 3 and 4 


User defined data-2 


32 




SDS 


c 


See notes 3 and 4 


User defined data-3 


64 




SDS 


c 


See notes 3 and 4 


Length indicator 


11 




SDS 


c 


See note 3 


User defined data-4 






SDS 


c 


See notes 3 and 5 


External subscriber number 




3 


SDS 







DIVI-MS address 




3 


CC 







NOTE 1 : This information element is used by SS-AS, refer to EN 300 392-12-8 [14]. 
NOTE 2: Shall be conditional on the value of Called Party Type Identifier (CPTI): 

- CPTI = 0; Called Party SNA; refer to ETS 300 392-1 2-7 [1 3] ; 

- CPTI = 1; Called Party SSI; 

- CPTI = 2; Called Party SSI + Called Party Extension. 

NOTE 3: Shall be conditional on the value of Short Data Type Identifier (SDTI): 

- SDTI = 0; User Defined Data-1 ; 

- SDTI = 1 ; User Defined Data-2; 

- SDTI = 2; User Defined Data-3; 

- SDTI = 3; Length indicator + User Defined Data-4. 

NOTE 4: Any combination of address and user defined data type is allowed. However, the intention is to fit 
TNSDS-UNITDATA request into one subslot when possible. It is recommended that always the 
shortest appropriate user defined data type is used. One subslot signalling is possible on 
a tt/4-DQI^SK or D8PSK channel by using one of the following combinations: 

- Short Number Address and User Defined Data 1 or 2; 

- Short Subscriber Identity and User Defined Data 1 . 

NOTE 5: The length of user defined data 4 is between and 2 047 bits. However, if the basic link is to be used, 
then the longest recommended length of the user defined data 4 is 1 017 bits while using Short 
Subscriber Identity and PCS on a tt/4-DQPSK channel (see clause 23.4.2.1 , see note 2). 
Clause 23.4.2.1 also indicates the longest recommended size of TIVI-SDU for fragmentation for other 
modulations and channel bandwidths; the longest recommended length of the user defined data 4 
using the basic link while using Short Subscriber Identity and PCS may be obtained by subtracting 
89 bits from the longest recommended size of TIVI-SDU (subject to the maximum length of 2 047 bits 
for user defined data 4). In order to avoid needing to know the modulation level to be used to send the 
SDS data on a D8PSK or QAIVI channel, the longest recommended length of the user defined data 4 
using the basic link on a D8PSK channel may be regarded as being the value for tt/4-DQPSK 
modulation, and the longest recommended length of the user defined data 4 using the basic link on a 
QAIVI channel may be regarded as being the value for 4-QAM rate = y2 for the appropriate channel 
bandwidth. 
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14.7.2.9 U-RELEASE 

• Message: U-RELEASE 

• Response to: D-DISCONNECT 

• Response expected: 

• Short description: This PDU shall be the acknowledgement to a disconnection. 

Table 14.29: U-RELEASE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


U-RELEASE 


Call identifier 


14 


1 


cc 


M 




Disconnect cause 


5 


1 


CC 


M 




Facility 




3 


ss 







Proprietary 




3 


- 








14.7.2.10 U-SETUP 

• Message: U-SETUP 

• Response to: 

• Response expected: D-CALL PROCEEDING/D-ALERT/D-CONNECT 

• Short description: This PDU shall be the request for a call set-up from a MS. 

Table 14.30: U-SETUP PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


U-SETUP 


Area selection 


4 




SS 


M 


See note 1 


Hook method selection 


1 




CC 


M 




Simplex/duplex selection 


1 




CC 


M 




Basic service information 


8 




CC 


M 




Request to transmit/send data 


1 




CC 


M 




Call priority 


4 




ss 


M 


See note 2 


CLIR control 


2 




ss 


M 


See note 3 


Called party type identifier 


2 




CC 


M 


Short/SSI/TSI 


Called party short number address 


8 




CC 


C 


See note 4 


Called party SSI 


24 




CC 


C 


See note 4 


Called party extension 


24 




CC 


C 


See note 4 


External subscriber number 




3 


CC 







Facility 




3 


ss 







DIVI-MS address 




3 


CC 







Proprietary 




3 


- 







NOTE 1 : This information element is used by SS-AS, refer to EN 300 392-12-8 [14]. 

NOTE 2: This information element is used by SS-PC, refer to EN 300 392-1 2-1 [1 5] and SS-PPC, refer to 

EN 300 392-12-16 [16]. 
NOTE 3: Refer to EN 300 392-1 2-1 [1 1 ]. 
NOTE 4: Shall be conditional on the value of Called Party Type Identifier (CPTI): 

- CPTI = 0; Called Party SNA; refer to ETS 300 392-1 2-7 [1 3] ; 

- CPTI = 1; Called Party SSI; 

- CPTI = 2; Called Party SSI + Called Party Extension. 
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14.7.2.11 U-TX CEASED 

• Message: U-TX CEASED 

• Response to: 

• Response expected: D-TX CEASED/D-TX GRANTED/D-TX WAIT 

• Short description: This PDU shall be the message to the SwMI that a transmission has ceased. 

Table 14.31 : U-TX CEASED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 


U-TX CEASED 


Call identifier 


14 


1 


cc 


M 




Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 








14.7.2.12 U-TX DEMAND 

• Message: U-TX DEMAND 

• Response to: D-TX GRANTED 

• Response expected: 

• Short description: This PDU shall be the message to the SwMI that a transmission is requested. 

Table 14.32: U-TX DEMAND PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 


U-TX DEMAND 


Call identifier 


14 




CC 


M 




TX demand priority 


2 




cc 


M 




Encryption control 


1 




cc 


M 




Reserved 


1 




cc 


M 


See note 


Facility 




3 


ss 







DIVI-MS address 




3 


cc 







Proprietary 




3 


- 







NOTE: This information element is not used in this version of the present document and its value shall be set 
to "0". 



1 4.7.3 PDU description tables - downlink and uplink 

14.7.3.1 General rules for function not supported 

The PDU defined in clause 14.7.3.2 may be used to indicate to the peer entity that the received PDU is not supported. Is 
shall be used only as a response to individually addressed PDUs. 

14.7.3.2 CMCE FUNCTION NOT SUPPORTED 

• Message: CMCE FUNCTION NOT SUPPORTED 

• Response to: Any individually addressed CMCE PDU 

• Response expected: 

• Short description: This PDU may be sent by the MS or SwMI to indicate that the received PDU 

is not supported. 
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Table 14.33: CMCE FUNCTION NOT SUPPORTED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


5 


1 


CC 


M 


See note 1 


Not-supported PDU type 


5 


1 


CC 


M 


See note 2 


Call identifier present 


1 


1 


CC 


M 




Call identifier 


14 




CC 


C 


See note 3 


Function-not-supported pointer 


8 


1 


CC 


M 


See note 4 


Length of received PDU extract 


8 




CC 


C 


See note 5 


Received PDU extract 


variable 




CC 


C 


See notes 5 and 6 


NOTE 1 : This information element shall have value "CMCE FUNCTION NOT SUPPORTED" as specified in 

clause 14.8.28. 
NOTE 2: This information element shall identify the PDU which contains the function which cannot be supported. 

The element shall have one of the values specified in clause 1 4.8.28. 
NOTE 3: This information element shall be present if the value of the Call identifier present information element 

is "1"; this information element shall not be present if the value of the Call identifier present information 

element is "0" (zero). 
NOTE 4: Element can have any value from to 255^0' '' non-zero, shall point to the first bit of the element in the 

received PDU which indicates the function that cannot be supported by the receiving entity. If zero, 

shall indicate that the PDU type itself (and hence the entire PDU specified by the "Not-supported PDU 

type" element) cannot be supported. 
NOTE 5: Shall be conditional on the value of Function-not-supported pointer: if Function-not-supported pointer is 

non-zero, this element shall be present; if Function-not-supported pointer is zero, this element shall not 

be present. 
NOTE 6: The total length of this element should be not less than the value of Function-not-supported pointer 

plus enough bits to identify the element in the received PDU which indicates the function that cannot be 

supported. This element shall not contain the PDU Type element of the received PDU because this is 

already specified by the "Not-supported PDU type" element (see note 2). 



14.8 Information elements coding 

Any of the following elements can be coded as Type 1, 2 or 3 depending on the PDU (see clause 14.7). 

14.8.1 Area Selection 

The area selection information element shall indicate to the SwMI the distribution of the call as defined in table 14.34. 
The SS-AS uses this information element, refer to EN 300 392-12-8 [14]. 

Table 14.34: Area selection information element contents 



Information element 


Length 


Value 


Remark 


Area Selection 


4 


OOOO2 


Area not defined using this information element 


0001 2 


Refer to EN 300 392-1 2-8 [1 4] 


etc. 


etc. 


IIII2 


Refer to EN 300 392-1 2-8 [14] 



ETSI 



278 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



14.8.2 Basic service information 

The basic service information element shall inform the other communication party what basic service is requested as 
defined in table 14.35. The total element length shall be 8 bits. 

Table 14.35: Basic service information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Circuit mode type 


3 


1 


M 




Encryption flag 


1 


1 


M 




Communication type 


2 


1 


M 




Slots per frame 


2 




C 


See note 


Speech service 


2 




C 


See note 


NOTE: Shall be conditional on the value of Circuit mode type: 

- Circuit mode type = OOO2 (Speech); Speech service; 

- Circuit mode type = any other value; Slots per frame. 



14.8.3 Call identifier 

The call identifier information element shall uniquely identify a specific call as defined in table 14.36. 

Table 14.36: Call identifier information element contents 



Information element 


Length 


Value 


Remark 


Call identifier 


14 





Dummy call identifier 


1 10 - 16 383io 


Identifies call uniquely 



14.8.3a Call identifier present 

The call identifier present information element shall indicate presence or otherwise of the call identifier element, as 
defined in table 14.37. 

Table 14.37: Call identifier present information element contents 



Information element 


Length 


Value 


Remark 


Call identifier present 


1 





Call identifier element not present 


1 


Call identifier element present 



14.8.4 Call ownership 

The call ownership information element in a group call shall indicate to the MS whether it is capable to disconnect the 
call or not as defined in table 14.38. In individual call it indicates to both parties if it is a normal call set-up or if it is 
amalgamated call. 

Table 14.38: Call ownership information element contents 



Information element 


Length 


Value 


Remark 


Call ownership 


1 





Not a call owner (Group call); 
Normal call set-up (Individual call) 


1 


A call owner (Group call); 
Amalgamated call (Individual call) 



ETSI 



279 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



1 4.8.5 Called party type identifier 

The called party type identifier information element shall indicate the type of address which shall follow in the PDU as 
defined in table 14.39. 

Table 14.39: Called party type identifier information element contents 



Information element 


Length 


Value 


Remark 


Called party type identifier 


2 


OO2 


Short Number Address (SNA) 


OI2 


Short Subscriber Identity (SSI) 


IO2 


TETRA Subscriber Identity (TSI) 


II2 


Reserved 



14.8.6 Called party SNA 

The called party SNA element shall indicate to the SwMI the SNA of the called user as defined in table 14.40. 
Table 14.40: Called party SNA information element contents 



Information element 


Length 


Value 


Remark 


Called party Short Number Address 


8 


- 255io 


See ETS 300 392-12-7 [13] 



14.8.7 Called party extension 

The called party extension information element shall be to indicate to the SwMI the extended part of the TSI address of 
the called user as defined in table 14.41. 

Table 14.41 : Called party extension information element contents 



Information sub-element 


Length 


Value 


Remark 


Country Code 


10 




See EN 300 392-1 [6], clause 7 


Network Code 


14 




See EN 300 392-1 [6], clause 7 



14.8.8 Called party SSI 

The Called party SSI information element shall indicate to the SwMI the SSI address of the called user as defined in 
table 14.42. 

Table 14.42: Called party SSI information element contents 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See EN 300 392-1 [6], clause 7 
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1 4.8.9 Calling party type identifier 

The calling party type identifier information element shall indicate the type of address which shall follow in the PDU as 
defined in table 14.43. 

Table 14.43: Calling party type identifier information element contents 



Information element 


Length 


Value 


Remark 


Calling Party Type Identifier 


2 


OO2 


Reserved 


OI2 


Short Subscriber Identity (SSI) 


IO2 


TETRA Subscriber Identity (TSI) 


II2 


Reserved 



1 4.8. 1 Calling party extension 

The calling party extension information element shall indicate the extended part of the TSI address of the calling user as 
defined in table 14.44. 

Table 14.44: Calling party extension information element contents 



Information sub-element 


Length 


Value 


Remark 


Country Code 


10 




See EN 300 392-1 [6] clause 7 


Network Code 


14 




See EN 300 392-1 [6] clause 7 



14.8.11 Calling party SSI 

The Calling party SSI information element shall indicate the SSI address of the calling user as defined in table 14.45. 
Table 14.45: Calling party SSI information element contents 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See EN 300 392-1 [6] clause 7 



14.8.12 Call priority 

The call priority information element shall inform the SwMI or the MS about the call priority as defined in table 14.46. 
The SS-PC and SS-PPC use this element, refer to EN 300 392-12-10 [15] and EN 300 392-12-16 [16]. 

Table 14.46: Call priority information element contents 



Information element 


Length 


Value 


Remark 


Call priority 


4 


OOOO2 


Priority not defined 


OOOI2 


Priority 1 (Lowest Priority) 


001 O2 


Priority 2 


etc. 


etc. 


IOII2 


Priority 1 1 


IIOO2 


Pre-emptive priority 1 


IIOI2 


Pre-emptive priority 2 


IIIO2 


Pre-emptive priority 3 


IIII2 


Pre-emptive priority 4 (Emergency) 
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14.8.13 Call Status 

The call status information element shall inform the MS about the status of the call as defined in table 14.47. 

Table 14.47: Call status information element contents 



Information element 


Length 


Value 


Remark 


Call status 


3 


OOO2 


Call is proceeding 


001 2 


Call is queued 


01 O2 


Requested subscriber is paged 


0112 


Call continue 


1002 


Hang time expired 


1012 


Reserved 


1102 


Reserved 


1112 


Reserved 



14.8.14 Call queued 

The call queued information element shall inform the calling MS that the call has been put in queue as defined in 
table 14.48. 

Table 14.48: Call queued information element contents 



Information element 


Length 


Value 


Remark 


Call queued 


1 





Call is not queued 


1 


Call is queued 



14.8.15 Continue 

The continue information element shall inform the MS if it shall continue after a pause in the same state as before the 
pause as defined in table 14.49. 

Table 14.49: Continue information element contents 



Information element 


Length 


Value 


Remark 


Continue 


1 





Not continue 


1 


Continue 
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14.8.16 Call time-out 

The call time-out information element shall set the maximum call time (T310) as defined in table 14.50. 

Table 14.50: Call time-out information element contents 



Information element 


Length 


Value 


Remark 


Call time-out 


4 


OOOO2 


Infinite Time 


OOOI2 


30 s 


001 O2 


45 s 


OOII2 


60s 


OIOO2 


2 min 


OIOI2 


3 min 


011 O2 


4 min 


01112 


5 min 


10002 


6 min 


10012 


8 min 


10102 


10 min 


10112 


12 min 


11002 


15 min 


11012 


20 min 


11102 


30 min 


11112 


Reserved 



1 4.8. 1 7 Call time-out, set-up phase 

The call time-out, set-up phase information element (T301 and T302) shall set the maximum set-up time valid for the 
call set-up phase as defined in table 14.51. 

Table 14.51 : Call time-out, set-up phase information element contents 



Information element 


Length 


Value 


Remark 


Call time-out, set-up phase 


3 


OOO2 


Use predefined value (see note) 


001 2 


1 s 


01 O2 


2s 


0112 


5s 


1002 


10s 


1012 


20 s 


1102 


30 s 


1112 


60s 


NOTE: This value shall indicate that the MS shall use a predefined value for the timer. 
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14.8. 17a Circuit mode type 

The circuit mode type information element shall indicate the TCH type and the interleaving depth N as defined in 
table 14.52 (see clause 8). 

Table 14.52: Circuit mode type information element contents 



Information element 


Length 


Value 


Remark 


Circuit mode type 


3 


OOO2 


Speech: 


TCH/S 


001 2 


Unprotected: 


TCH/7,2 


01 O2 


Low Protection: 


TCH/4,8, N = 1 


0112 


Low Protection: 


TCH/4,8, N = 4 


1002 


Low Protection: 


TCH/4,8, N = 8 


1012 


High Protection: 


TCH/2,4, N = 1 


1102 


High Protection: 


TCH/2,4, N = 4 


1112 


High Protection: 


TCH/2,4, N = 8 



14.8.17bCLIR control 

The CLIR control information element shall define whether the calling user invokes or overrides calling user identity 
presentation restriction as defined in table 14.53, refer to EN 300 392-12-1 [11]. 

Table 14.53: CLIR control information element contents 



Information element 


Length 


Value 


Remark 


CLIR control 


2 


OO2 


Not implemented or use default mode 


OI2 


Reserved 


IO2 


Presentation not restricted 


II2 


Presentation restricted 



1 4.8.1 7c Communication type 

The communication type information element shall inform the other communication party which type of 
communication service is requested as defined in table 14.54. 

Table 14.54: Communication type information element contents 



Information sub-element 


Length 


Value 


Remark 


Communication type 


2 


OO2 


Point-to-point 


OI2 


Point-to-multipoint 


IO2 


Point-to-multipoint Acknowledged 


II2 


Broadcast 
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1 4.8. 1 8 Disconnect cause 

The disconnect cause information element shall inform the MS or the infrastructure of the reason for the 
release/disconnection as defined in table 14.55. 

Table 14.55: Disconnect cause information element contents 



Information element 


Length 


Value 


Remark 


Disconnect cause 


5 


OOOOO2 


Cause not defined or unknown 


00001 2 


User requested disconnect 


0001 O2 


Called party busy 


00011 2 


Called party not reachable 


001 OO2 


Called party does not support encryption 


001012 


Congestion in infrastructure 


001 IO2 


Not allowed traffic case 


001 II2 


Incompatible traffic case 


010002 


Requested service not available 


010012 


Pre-emptive use of resource 


010102 


Invalid call identifier 


010112 


Call rejected by the called party 


011002 


No idle CC entity 


011012 


Expiry of timer 


011102 


SwIVII requested disconnection 


011112 


Acknowledged service not completed 


100002 


Unknown TETRA identity 


10001 2 


SS-specific disconnection 


100102 


Unknown external subscriber identity 


100112 


Call restoration of the other user failed 


101002 


Called party requires encryption 


101012 


Concurrent set-up not supported 


101102 


Called party is under the same DM-GATE of the calling party 


101112 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 



1 4.8.1 8a DM-MS address 

For the definition of the DM-MS address information element refer to EN 300 396-5 [24]. 

14.8.19 DTMF 

The DTMF information element shall transfer DTMF digits (n digits where n shall be less than or equal to 254) to 
another user application as defined in table 14.56. 

Table 14.56: DTMF information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


DTMF type 


3 


1 


M 




DTIVIF digit 


4 




C 


See notes 1 and 2 


NOTE 1 : Shall be conditional on the value of DTMF type: 

- DTMF type = OOO2 (DTMF tone start); DTMF digit(s) present; 

DTMF type = any other value; DTMF digit information element not present. 

NOTE 2: This element, if present, shall be repeated for each digit in the DTMF number. 
The number of DTMF digits in the DTMF number information element is: 
(the length of the DTMF information element - 3) / 4. 
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1 4.8.1 9a DTMF digit 

The DTMF digit information element shall define the numerical values for DTMF digits as defined in table 14.57. 

Table 14.57: DTMF digit information element contents 



Information element 


Length 


Value 


Remark 


DTMF digit 


4 


OOOO2 


Digit "0" 


OOOI2 


Digit "1" 


001 O2 


Digit "2" 


OOII2 


Digit "3" 


OIOO2 


Digit "4" 


OIOI2 


Digit "5" 


011 O2 


Digit "6" 


01112 


Digit "7" 


10002 


Digit "8" 


10012 


Digit "9" 


10102 


Digit "*" 


10112 


Digit "#" 


11002 


Digit "A" 


11012 


Digit "B" 


11102 


Digit "C" 


11112 


Digit "D" 



14.8.1 9b DTMF type 

The DTMF type information element shall define DTMF tone characteristics as defined in table 14.58. 

NOTE: The length of this information element is chosen so that a receiving application can differentiate between 
the DTMF signalling mechanisms used in edition 1 and this version of the present document based on the 
total length of the DTMF information element (length is exactly divisible by 4 for the edition 1 
mechanism and not exactly divisible by 4 for this version). 

Table 14.58: DTMF type information element contents 



Information element 


Length 


Value 


Remark 


DTIVIF type 


3 


OOO2 


DTIVIF tone start 


GDI 2 


DTMF tone end 


01 O2 


DTMF not supported 


OII2 


DTMF not subscribed 


IOO2 


Reserved 


etc. 


etc. 


III2 


Reserved 
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1 4.8.20 External subscriber number 

The external subscriber number information element shall transfer a subscriber number from a TETRA subscriber to a 
gateway or from a gateway to a TETRA subscriber. The external subscriber number can consist of n digits where n shall 
be less than or equal to 24. The number of digits is indicated by the preceding type 3 element length divided by four. 

The digits of the external subscriber number shall be in descending order (as normally dialled in man machine interface) 
in the information element. Each digit in the external subscriber number information element shall be encoded as 
defined in table 14.59. 

Table 14.59: Encoding of the digits in the external subscriber number information element 



Information element 


Length 


Value 


Remark 


External subscriber number digit 


4 


OOOO2 


Digit "0" 


OOOI2 


Digit "1" 


001 O2 


Digit "2" 


OOII2 


Digit "3" 


OIOO2 


Digit "4" 


OIOI2 


Digit "5" 


011 O2 


Digit "6" 


01112 


Digit "7" 


10002 


Digit "8" 


10012 


Digit "9" 


10102 


Digit "*" 


10112 


Digit "#" 


11002 


Digit "+" 


11012 


Reserved 


11102 


Reserved 


11112 


Reserved 



14.8.21 Encryption control 

The encryption control information element shall able an MS to request for encryption/clear mode and then be informed 
about the granting result of this request as defined in table 14.60. 

Table 14.60: Encryption control information element contents 



Information element 


Length 


Value 


Remark 


Encryption control 


1 





Clear 


1 


End-to-end encrypted 



1 4.8.21 a Encryption flag 

The encryption flag information element shall indicate whether the circuit mode speech or data is end-to-end encrypted 
as defined in table 14.61. 

Table 14.61 : Encryption flag information element contents 



Information sub-element 


Length 


Value 


Remark 


Encryption flag 


1 





Clear IVIode 


1 


TETRA end-to-end encryption 
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14.8.22 Facility 



The facility information element shall be an optional variable length element and shall be used to send and receive SS 
information appended to the PDUs which can carry the facility element. 

The size and the structure of the facility information element shall be dependent on each individual SS and shall be 
further detailed in the SS protocol clauses, refer to EN/ETS 300 392-12 [10]. 

There can be multiple facility information elements in the same PDU although a single facility information element can 
carry multiple supplementary services, refer to EN 300 392-9 [9]. 

1 4.8.23 HooW metlnod selection 

The hook method selection information element shall inform the infrastructure and the called user(s) of the preferred 
hook method as defined in table 14.62. 

Table 14.62: Hook method selection information element contents 



Information element 


Length 


Value 


Remark 


Hook method selection 


1 





No hook signalling (direct through-connect) 


1 


Hook on/Hook off signalling 



14.8.24 Length indicator 

The length Indicator information element shall define the length of the user defined data-4 as defined in table 14.63. 
Table 14.63: Length indicator information element contents 



Information element 


Length 


Value 


Remark 


Length indicator 


11 





Obits 






1 


1 bit 






etc. 


etc. 






(2^^-1) 


2 047 bits 



14.8.25 New call identifier 

The new call identifier information element coding shall be the same as for the call identifier element. 

14.8.26 Modify 

The modify information element shall change an ongoing call either to a new basic service or the behaviour from 
simplex to duplex or reverse as defined in table 14.64. 

Table 14.64: Modify information element contents 



Information sub-element 


Length 


Value 


Remark 


Simplex/duplex selection 


1 




See description of "Simplex/duplex selection" element 


Basic service information 


8 




See description of "Basic service information" element 
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14.8.27 Notification indicator 

The notification indicator information element shall be used in SSs by the SwMI to inform a MS of various events as 
defined in table 14.65. 

Table 14.65: Notification indicator information element contents 



Information element 


Length 


Value 


Remark 


Notification indicator 


6 


0to63io 


Refer to EN 300 392-9 [9] clause 7.2.2 



1 4.8.27a Otiner party type identifier 



The other party type identifier information element coding shall be the same as for the called party type identifier 
element, refer to clause 14.8.5. 



14.8.27bOther party SNA 



The other party SNA information element coding shall be the same as for the called party SNA element, refer to 
clause 14.8.6. 



1 4.8.27c Otiner party extension 



The other party extension information element coding shall be the same as for the called party extension element, refer 
to clause 14.8.7. 



14.8.27d Other party SSI 



The other party SSI information element coding shall be the same as for the called party SSI element, refer to 
clause 14.8.8. 
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14.8.28 PDUtype 

The PDU type information element shall identify the type of CMCE PDU sent over the air interface. The PDU type 
information element shall have separate definitions in the uplink and downlink directions as defined in table 14.66. 

Table 14.66: PDU type information element contents 



Information element 


Length 


Value 


Remark 


Downlink 


Uplink 


PDU Type 


5 


OOOOO2 


D-ALERT 


U-ALERT 


00001 2 


D-CALL-PROCEEDING 


Reserved 


0001 O2 


D-CONNECT 


U-GONNEGT 


00011 2 


D-CONNECT ACKNOWLEDGE 


Reserved 


001 OO2 


D-DISGONNEGT 


U-DISGONNEGT 


001012 


D-INFO 


U-INFO 


001 IO2 


D-RELEASE 


U-RELEASE 


001 II2 


D-SETUP 


U-SETUP 


010002 


D-STATUS 


U-STATUS 


010012 


D-TX GEASED 


U-TX GEASED 


010102 


D-TXGONTINUE 


U-TX DEMAND 


010112 


D-TX GRANTED 


Reserved 


011002 


D-TX WAIT 


Reserved 


011012 


D-TX INTERRUPT 


Reserved 


011102 


D-GALL-RESTORE 


U-GALL-RESTORE 


011112 


D-SDS-DATA 


U-SDS-DATA 


100002 


D-FAGILITY 


U-FAGILITY 


10001 2 


Reserved 


Reserved 


100102 


Reserved 


Reserved 


etc. 


etc. 


etc. 


IIIII2 


GMGE FUNGTION NOT 
SUPPORTED 


GMGE FUNGTION NOT 
SUPPORTED 



14.8.29 Poll request 

This poll request information element shall be used by the SwMI to request a poll response back from the MS when an 
acknowledged group call has been initiated as defined in table 14.67. 

Table 14.67: Poll request information element contents 



Information element 


Length 


Value 


Remark 


Poll request 


1 





No poll answer requested 


1 


Poll answer requested 



14.8.30 Poll response 

This poll response information element shall be used by the MS to respond to a poll request in an acknowledged group 
call from the SwMI as defined in table 14.68. 

Table 14.68: Poll response information element contents 



Information element 


Length 


Value 


Remark 


Poll response 


1 





No poll response 


1 


Poll response 



ETSI 



290 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



14.8.31 Poll response addresses 

The poll response addresses information element shall provide the addresses on responding group members in an 
acknowledged group call as defined in table 14.69. 

Table 14.69: Poll response addresses information element contents 



Information element 


Length 


Value 


Remark 


IstlSI address 


48 




See EN 300 392-1 [6], clause 7 


2nd TSI address 


48 






etc. 


etc. 






nth TSI address 


48 







14.8.32 Poll response number 

The poll response number information element shall provide the number of responding group members in an 
acknowledged group call as defined in table 14.70. 

Table 14.70: Poll response number information element contents 



Information element 


Length 


Value 


Remark 


Number of responding group members 


6 


0to63io 





14.8.33 Poll response percentage 

The poll response percentage information element shall provide the percentage of responding group members in an 
acknowledged group call as defined in table 14.71. 

Table 14.71 : Poll response percentage information element contents 



Information element 


Length 


Value 


Remark 


Percentage of responding number 
of group members 


6 





0% 


1 


2% 


etc. 


etc. 


50io 


100% 


51io 


Reserved 


etc. 


etc. 


63-10 


Reserved 
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14.8.34 Pre-coded status 

The pre-coded status information element shall define general purpose status messages known to all TETRA systems as 
defined in table 14.72 and shall provide support for the SDS-TL "short reporting" protocol. 

Table 14.72: Pre-coded status information element contents 



Information element 


Length 


Value 


Remark 


Pre-coded status 


16 





Emergency 


1 


Reserved 


etc. 


etc. 


31 743io 


Reserved 


31 744io 


Refer to SDS-TL in clause 29 


etc. 


etc. 


32 767io 


Refer to SDS-TL in clause 29 


32 768io 


Available for TETRA network and user specific definitions 


etc. 


etc. 


65 535io 


Available for TETRA network and user specific definitions 



14.8.35 Proprietary 

Proprietary is an optional, variable length information element and shall be used to send and receive proprietary defined 
information appended to the PDUs as defined in table 14.73. The proprietary element is terminated in CMCE. 

The use, the size and the structure of the proprietary element is outside the scope of the present document. 

Table 14.73: Proprietary information element contents 



Information element 


Length 


Value 


Remark 


Proprietary element owner 


8 


variable 


Refer to annex H 


Proprietary information 


variable 


variable 


Contents is outside the scope of the present document 



1 4.8.36 Request to transmit/send data 

The request to transmit/send data information element shall inform the infrastructure about immediate request to 
transmit or data transmission at through-connection as defined in table 14.74. 

Table 14.74: Request to transmit/send data information element contents 



Information element 


Length 


Value 


Remark 


Request to transmit/send data 


1 





Request to transmit/send data 


1 


Request that other MS may transmit/send data 



1 4.8.37 Reset call time-out timer (T31 0) 



The reset call time-out timer information element shall reset and start the overall call length timer T310 in the MS as 
defined in table 14.75. 

Table 14.75: Reset call time-out timer information element contents 



Information element 


Length 


Value 


Remark 


Reset call time-out value 


1 





No reset of call time-out timer T31 


1 


Reset call time-out timer T31 
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1 4.8.38 Short data type identifier 

The short data type identifier information element shall identify the length of the user defined data sent to or received 
from the SwMI as defined in table 14.76. 

Table 14.76: Short data type identifier information element contents 



Information element 


Length 


Value 


Remark 


Short data type identifier 


2 


OO2 


User Defined Data 1 element is 16 bits long 


OI2 


User Defined Data 2 element is 32 bits long 


IO2 


User Defined Data 3 element is 64 bits long 


II2 


User Defined Data 4 element is to 2 047 bits long (variable length) 



14.8.39 Simplex/duplex selection 

The simplex/duplex selection information element shall be to inform the infrastructure the preferred mode of operation 
as defined in table 14.77. 

Table 14.77: Simplex/duplex selection information element contents 



Information element 


Length 


Value 


Remark 


Simplex/duplex selection 


1 





Simplex requested 


1 


Duplex requested 



14.8.39a Slots per frame 

The slots per frame information element shall indicate the required bit rate for a circuit mode data call as defined in 
table 124a. For TCH/7,2, TCH/4,8 and TCH/2,4 the resulting bit rate is the TCH bit rate multiplied by the number of 
slots per frame, (e.g. TCH/7,2 in four time slots per frame gives a circuit mode data rate of 28,8 kbit/s). 

Table 14.78: Slots per frame information element contents 



Information sub-element 


Length 


Value 


Remark 


Slots per frame 


2 


OO2 


One slot 


OI2 


Two slots 


IO2 


Three slots 


II2 


Four slots 



14.8.40 Speech service 

The speech service information element shall indicate the required speech and channel encoding as defined in 
table 14.79. 

Table 14.79: Speech service information element contents 



Information element 


Length 


Value 


Remark 


Speech service 


2 


OO2 


TETRA encoded speech 


OI2 


Reserved 


IO2 


Reserved 


II2 


Proprietary encoded speech 



14.8.41 Temporary address 

The temporary address information element coding shall be the same as for the SSI element. 
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14.8.42 Transmission grant 

The transmission grant information element shall inform the MS about permission to transmit as defined in table 14.80. 
Table 14.80: Transmission grant information element contents 



Information element 


Length 


Value 


Remark 


Transmission grant 


2 


OO2 


Transmission granted 


OI2 


Transmission not granted 


IO2 


Transmission request queued 


II2 


Transmission granted to anotlier user 



14.8.43 Transmission request permission 

The transmission request permission information element shall inform the MS if it is allowed to request for transmit 
permission as defined in table 14.81. 

Table 14.81: Transmission request permission information element contents 



Information element 


Length 


Value 


Remark 


Transmission request permission 


1 





Allowed to request for transmission 


1 


Not allowed to request for transmission 



1 4.8.44 Transmitting party type identifier 

The transmitting party type identifier information element coding shall indicate the type of address which shall follow 
in the PDU as defined in table 14.82. 

Table 14.82: Transmitting party type identifier information element contents 



Information element 


Length 


Value 


Remark 


Transmitting party type identifier 


2 


OO2 


Reserved 


OI2 


Short Subscriber Identity (SSI) 


IO2 


TETRA Subscriber Identity (TSI) 


II2 


Reserved 



14.8.45 Transmitting party extension 

The transmitting party extension information element shall indicate the extended part of the TSI address of the 
transmitting user as defined in table 14.83. 

Table 14.83: Transmitting party extension information element contents 



Information sub-element 


Length 


Value 


Remark 


Country Code 


10 




See EN 300 392-1 [6], clause 7 


Network Code 


14 




See EN 300 392-1 [6], clause 7 
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14.8.46 Transmitting party SSI 

The transmitting party SSI information element shall indicate the SSI address of the transmitting user as defined in 
table 14.84. 

Table 14.84: Transmitting party SSI information element contents 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See EN 300 392-1 [6], clause 7 



1 4.8.47 TX demand priority 

The TX demand priority information element shall inform the SwMI about the importance of a TX-Demand as defined 
in table 14.85. 

Table 14.85: Tx demand priority information element contents 



Information element 


Length 


Value 


Remark 


TX demand priority 


2 


OO2 


Low priority level 


OI2 


High priority level 


IO2 


Pre-emptive priority level 


II2 


Emergency pre-emptive priority level 



1 4.8.48 Type 3 element identifier 

The type 3 element identifier information element shall indicate the type of the following type 3 element in the PDU as 
defined in table 14.86. 

Table 14.86: Type 3 element identifier information element contents 



Information element 


Length 


Value 


Remark 


Type 3 element identifier 


4 


OOOO2 


Reserved 


0001 2 


DTMF 


001 O2 


External subscriber number 


0011 2 


Facility 


01002 


Poll response addresses 


01012 


Temporary address 


01102 


DIVI-MS address 


01112 


Reserved for any future specified Type 3 element 


etc. 


etc. 


IIII2 


Proprietary 



1 4.8.49 User defined data-1 

The User Defined Data-1 information element shall enable the user applications to determine their own interpretation of 
the SDS message as defined in table 14.87. 

Table 14.87: User Defined Data-1 information element contents 



Information element 


Length 


Value 


Remark 


User Defined Data-1 


16 


to (216- 1) 


All values available for the user application 



ETSI 



295 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



1 4.8.50 User defined data-2 

The User Defined Data-2 information element shall enable the user applications to determine their own interpretation of 
the SDS message as defined in table 14.88. 

Table 14.88: User Defined Data-2 information element contents 



Information element 


Length 


Value 


Remark 


User Defined Data-2 


32 


to (232 . 1 ) 


All values available for the user application 



1 4.8.51 User defined data-3 

The User Defined Data-3 information element shall enable the user applications to determine their own interpretation of 
the SDS message as defined in table 14.89. 

Table 14.89: User Defined Data-3 information element contents 



Information element 


Length 


Value 


Remark 


User Defined Data-3 


64 


to (264- 1) 


All values available for the user application 



1 4.8.52 User defined data-4 

The User Defined Data-4 information element shall enable the user applications to determine their own interpretation of 
the SDS message as defined in table 14.90. The first 8 bits of the user defined data-4 element shall contain a protocol 
identifier as defined in clause 29. 

Table 14.90: User Defined Data-4 information element contents 



Information element 


Length 


Value 


Remark 


Protocol identifier 


8 


variable 


Refer to clause 29 


Protocol dependent User 
Defined Data-4 


variable 
(0 to 2 039 bits) 


variable 


Refer to clause 29 
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15 Mobility IVIanagement (IVIIVI) service description 

15.1 Introduction 

This clause describes the services offered by the MM entity (see EN 300 392-1 [6], clause 6) for the V+D TETRA 
layer 3 air interface. The MM SAP is used in conformance testing as a normative boundary in TETRA MSs. 

15.2 Services offered 

The MM shall be a service provider for mobility service users on the layer 3 MS air interface. The services shall be 
made available through a TETRA Network Mobility Management Service Access Point (TNMM-SAP) (see 
EN 300 392-1 [6], clause 6) which is shown in figure 15.1. The protocol description is defined in clause 16. 

The services offered by MM are: 

• registration (mandatory), this service shall allow a user to register manually to the network, the user shall be 
then informed of the result of the registration. When a MS roams or migrates the user application shall be also 
informed that the MS is ready for use or that registration was not possible (see EN 300 392-1 [6], clause 9); 

• de-registration (detach) (optional), this service allows a user to request cancellation of the registration; 

• change of energy saving mode (optional), this service shall allow the user to ask for changing the energy 
saving mode with confirmation or to receive and to respond to an energy saving mode allocation; 

• change of dual watch mode (optional), this service allows the user to ask for dual watch operation with an 
appropriate energy economy group or to end dual watch operation; 

• attachment/detachment of group identities (optional), this service shall allow the user application to either 
activate or deactivate already defined group identities in the MS/LS. The service shall also inform the user 
applications of the result of the attachment/detachment of the group identities both when the user application 
initiates the attachment/detachment or when the SwMI initiates the attachment/detachment; 

• information concerning state of the mobile (optional). 

NOTE: Enable, disable service is defined in EN 300 392-7 [8], this service allows a user to be aware of the 

temporary or permanent disabling asked by the network. The user application is also made aware of the 
cessation of a temporary disable. 



ETSI 



297 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



15.3 Primitive description 



The services shall be provided through primitives at the TNMM-SAP. Clauses 15.3.1 to 15.3.4 describe the primitives 
and their parameters. Clauses 15.3.5 and 15.3.6 describe states and state transitions. 

1 5.3.1 Service state model for the IVIS 

The primitives provided at the TNMM-SAP are illustrated in figure 15.1. 





















SIGNAL \ 
TNMM-ATTACH DETACH GROUP ID request, 
TNMM-ATTACH DETACH GROUP ID indication, 
TNMM-ATTACH DETACH GROUP ID confirm, 
TNMM-DEREGISTRATION request, 
TNMM-DISABLING indication, 
TNMM-ENABLING indication, 
TNMM-ENERGY SAVING confirm, 
TNMM-ENERGY SAVING request, 
TNMM-REGISTRATION confirm, 
TNMM-REGISTRATION indication, 
TNMM-REGISTRATION request, 
TNMM-REPORT indication, 
TNMM-SERVICE indication; 
TNMM-STATUS indication; 
TNMM-STATUS request; 
TNMM-STATUS confirm. 




TNMM-ATTACH DETACH GROUP ID indication, 
TNMM-ATTACH DETACH GROUP ID confirm, 
TNMM-REPORT indication, 
TNMM-DISABLING indication, 
TNMM-ENABLING indication, 
TNMM-ENERGY SAVING confirm, 
TNMM-REGISTRATION confirm, 
TNMM-REGISTRATION indication, 
TNMM-SERVICE indication; 
TNMM-STATUS indication; 
TNMM-STATUS confirm; 






TNMMSAP <^ 


> 






TNMM-ATTACH DETACH GROUP ID request, 
TNMM-DEREGISTRATION request, 
TNMM-ENERGY SAVING request 




/ 










TNMM-REGISTRATION request; 
TNMM-STATUS request; 


- 






MM SERVICE 
MS 

















NOTE: TNMM-DISABLING and TNMM-ENABLING primitives are defined in EN 300 392-7 [8]. 
Figure 15.1 : Services provided at TNIUIIUI-SAP/IVIS-side 

1 5.3.2 Service primitives at tine TNIVIIVI-SAP, IVIS/LS side 

The set of MM primitives that are available to provide the specified service to the user application shall be: 

• TNMM-ATTACH DETACH GROUP IDENTITY request/indication/confirm: the primitives shall be 
used to handle activation and deactivation of defined GTSIs in the MS/LS or to request group report from 
SwMI; 

• TNMM-DEREGISTRATION request: the primitive shall be used to handle detachment of attached ITSIs; 

• TNMM-ENERGY SAVING indication /request/confirm: the primitives shall be used to exchange energy 
saving mode of operation to the SwMI; 

• TNMM-REGISTRATION request/indication/confirm: the primitives shall be used to handle attachment of 
ITSIs and can as well be used for activation/de-activation of GSSIs; 

• TNMM-REPORT indication: the primitive shall be used to inform the user application of a successful or 
unsuccessful transmission of U-ITSI DETACH; 

• TNMM-SERVICE indication: the primitive shall be used as an indication to the user application to reflect 
the service state of the MS, i.e. whether it shall be possible to initiate or receive communication using the 
current network; 
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• TNMM-STATUS request/indication/response/confirm: the primitives shall be used for various mobility 
management services. 

15.3.3 Primitive description 

The information contained in the primitive description tables which follow corresponds to the following key: 
M: Mandatory; 
C: Conditional; 
O: Optional; 
-: Not used. 

1 5.3.3.1 TNMM-ATTACH DETACH GROUP IDENTITY primitive 

TNMM-ATTACH DETACH GROUP IDENTITY request: the primitive shall be used by the user application to 
activate or deactivate one or more defined group identities in the MS/LS or ask for group report. 

TNMM-ATTACH DETACH GROUP IDENTITY indication: the primitive shall be used an indication to the user 
application when the SwMI has activated or de-activated one or more defined group identities in the MS/LS. 

TNMM-ATTACH DETACH GROUP IDENTITY confirm: the primitive shall be used as an indication to the user, 
that the requested activation or de-activation of group identities is negotiated between the MS/LS and the SwMI. 

The parameters shall be as defined in table 15.1. 

Table 15.1 : Parameters for the primitive TNI\fll\fl-ATTACH DETACH GROUP IDENTITY 



Parameter 


Request 


Indication 


Confirm 


Group identity attach detach mode 


M 


- 


M 


Group identity request 


M 


- 


- 


Group identity report 





- 





Group identities 


- 


M 


M 



15.3.3.2 TNMM-DEREGISTRATION primitive 

TNMM-DEREGISTRATION request: the primitive shall be used to request to cancel the registration, stimulated 
either by removing the "ITSI identity" or a "log-off" application or automatically in the power off phase. 

The parameters shall be as defined in table 15.2. 

Table 15.2: Parameters for the primitive TNMM-DEREGISTRATION 



Parameter 


Request 


ISSI 





MCC 





MNC 





NOTE: In case all the attached ITSIs are detached, the parameters need not to be present. 



15.3.3.3 TNMM-DISABLING primitive 

Refer to EN 300 392-7 [8], clause 5. 

15.3.3.4 TNMM-ENABLING primitive 

Refer to EN 300 392-7 [8], clause 5. 
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1 5.3.3.5 TNMM-ENERGY SAVING primitive 

TNMM-ENERGY SAVING indication: the primitive shall be used to indicate to the user application a start or change 
of energy economy mode the SwMI wants to use. 

TNMM-ENERGY SAVING request: the primitive shall be used by the user application to change or re-state to the 
SwMI what energy economy mode the MS wants to use. 

TNMM-ENERGY SAVING confirm: the primitive shall be used as a confirmation to the user application that the 
changed or re-stated energy economy mode has been reported to the SwMI. 

The parameters shall be as defined in table 15.3. 

Table 15.3: Parameters for the primitive TNIVIIVI-ENERGY SAVING 



Parameter 


Request 


Confirm 


Indication 


Energy economy mode 


M 


M 





Energy economy mode status 


- 


M 






15.3.3.6 TNMM-REPORT primitive 

TNMM-REPORT indication: the primitive shall be used to inform the user application of a successful or unsuccessful 
transmission of U-ITSI DETACH. 

The parameters shall be as defined in table 15.4. 

Table 15.4: Parameters for the TNMM-REPORT primitive 



Parameter 


Indication 


Transfer result 


M 



15.3.3.7 TN MM- REGISTRATION primitive 

TNMM-REGISTRATION request: the primitive shall be used by the user application to initiate attachment and 
registration of the terminal. 

TNMM-REGISTRATION indication: the primitive shall be used as an indication to the user application that the 
LS/MS has carried out registration procedure (either successfully or unsuccessfully) or that LA registration is expired. 

TNMM-REGISTRATION confirm: the primitive shall be used to inform the user application that registration is 
confirmed. The primitive may be used to inform the user that the MS/LS is ready for use. 

The parameters shall be as defined in table 15.5. 
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Table 15.5: Parameters for the primitive TNIVIIUI-REGISTRATION 



Parameter 


Request 


Indication 


Confirm 


Registration status 


- 


M 


M 


Registration reject cause (see note 1) 


- 


C 


C 


LA (where registered) 


- 


M 


M 


IVICC (where registered) 


- 


M 


M 


IVINC (where registered) 


- 


M 


M 


Registration type 


M 


- 


- 


Preferred LA list (see note 2) 





- 


- 


Preferred MCC list (see note 3) 





- 


- 


Preferred MNC list (see note 3) 





- 


- 


ISSI 


M 


- 


- 


MCC (of the ISSI) 


M 


- 


- 


MNC (of the ISSI) 


M 


- 


- 


Energy economy mode 











Energy economy mode status 


- 








Group identities 


- 








Group identity request 





- 


- 


Group identity attach/detach mode 











NOTE 1 : Shall be present if Registration Status = "failure". 

NOTE 2: Shall be present if Registration Type = "No new ITS! - forward registration". 

NOTE 3: Shall be present if Registration Type = "New ITSI"; or 

Registration Type = "No new ITSI - forward registration". 
NOTE 4: Shall be used when the registration status indicates "LA registration is expired". 



15.3.3.8 TNMM-SERVICE primitive 

TNMM-SERVICE indication: the primitive shall be used as an indication to the user application to reflect the service 
state of the MS, i.e. whether it shall be possible to initiate or receive communication using the current network. 

The parameters shall be as defined in table 15.6. 

Table 15.6: Parameters for the primitive TNIUIM-SERVICE 



Parameter 


Indication 


Service status 


M 


Disable status 


M 



15.3.3.9 TNMM-STATUS primitive 

TNMM-STATUS request: the primitive shall be used to request various mobility management services. 

TNMM-STATUS indication: the primitive shall indicate to the user application a mobility management service or 
action request. 

TNMM-STATUS confirm: the primitive shall indicate to the user application the result of a request. 

The parameters shall be as defined in table 15.7. 

NOTE: The energy economy mode is also managed by this primitive. 

Table 15.7: Parameters for the primitive TNIUIM-STATUS 



Parameter 


Request 


Indication 


Confirm 


Service status 




M 




Disable status 




M 




Direct mode 





- 


- 


Dual watch 











Energy economy mode (see note) 











NOTE: This parameter is applicable with the dual watch parameter. 
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15.3.4 Parameters description 



Parameters shall be part of the primitives described in clause 15.3.3 and if appUed the parameters shall contain the 
values specified in this clause. 

• Class of usage = 

Class of Usage 1; 
Class of Usage 2; 
Class of Usage 3; 
Class of Usage 4; 
Class of Usage 5; 
Class of Usage 6; 
Class of Usage 7; 
Class of Usage 8. 

• Disable status = 

enabled; 

temporary disabled; 
permanently disabled. 

• Dual watch = 

starting dual watch mode; 

modify or resume dual watch mode; 

dual watch mode accepted; 

dual watch mode rejected; 

dual watch mode not supported; 

terminating dual watch mode; 

terminating dual watch mode response; 

dual watch energy economy group changed by SwMI; 

dual watch mode terminated by SwMI. 

• Direct mode = 

start of direct mode operation. 
NOTE: A return to trunking mode is a normal registration. 
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Energy economy mode = 

stay alive; 

energy economy mode 1 ; 

energy economy mode 2; 

energy economy mode 3; 

energy economy mode 4; 

energy economy mode 5; 

energy economy mode 6; 

energy economy mode 7. 
Energy economy mode status = 

accepted; 

rejected. 
Group identities = 

Table 15.8: Group identities parameter 



Parameter 


C/O/M 


Remark 


GTSI 


M 




Group Identity Attach/detach Type Identifier 


M 




Group Identity Lifetime 


C 


See note 


Class of Usage 


C 


See note 


Group Identity Detachment Reason 


c 


See note 


NOTE: Shall be conditional on the value of Group Identity Type Identifier (GITI). 

- GITI = Attachment; Group Identity Lifetime + Class of Usage; 

- GITI = Detachment; Group Identity Detachment Reason. 



Group identity attach/detach mode = 

amendment; 

detach the currently active group identities. 
Group identity request = 



Table 15.9: Group identity request parameter 



Parameter 


C/O/M 


Remark 


GTSI 


M 




Group Identity Attach/detach Type Identifier 


M 




Class of Usage 


C 


See note 


Group Identity Detachment Request 


C 


See note 


NOTE: Shall be conditional on the value of Group Identity Type Identifier (GITI). 

- GITI = Attachment; Class of Usage; 

- GITI = Detachment; Group Identity Detachment. 



Group identity Attach/detach type identifier : 
attachment; 
detachment. 
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Group identity lifetime = 

permanent, attachment not needed; 

attachment needed for next ITSI- Attach; 

attachment not allowed after next ITSI- Attach; 

attachment needed for next location update. 
Group identity detachment = 

permanently detached; 

temporary 1 detached; 

temporary 2 detached; 

unknown group identity. 
Group identity detachment request = 

user initiated detachment. 
Group identity report = 

report requested; 

report not requested. 
GTSI = 

Group TETRA Subscriber Identity. 
ISSI = 

Individual Short Subscriber Identity. 
LA = 

location area. 
MCC = 

Mobile Country Code (see EN 300 392-1 [6], clause 7). 
MNC = 

MNC (see EN 300 392-1 [6], clause 7). 
Preferred LA list = 

list of LA identities. 
Preferred MCC list = 

list of MCC identities. 
Preferred MNC list = 

list of MNC identities . 
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Registration reject cause = 

ITSI unknown; 

illegal MS; 

LA not allowed; 

LA unknown; 

network failure; 

congestion; 

forward registration failure; 

service not subscribed; 

mandatory element error; 

message consistency error; 

roaming not supported; 

migration not supported; 

no cipher KSG; 

identified cipher KSG not supported; 

requested cipher key type not available; 

identified cipher key not available; 

ciphering required; 

authentication failure. 
Registration status = 

success; 

failure; 

LA registration expired; 

no preferred cell found. 
Registration type = 

periodic registration; 

registration to indicated cell. 
Service status = 

in service; 

in service waiting for registration; 

out of service; 

MM busy; 

MM idle. 
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• Transfer result = 

transfer successful done; 
transfer fail. 

1 5.3.5 State description for tine MS 

The following clauses define the status of the different states used within the SDL description given in clause 15.3.6. 

15.3.5.1 Not updated 

This state shall be used when the MS is ready for a registration request. 

15.3.5.2 Wait updating 

This shall be an intermediate state while the network is processing the registration request. 

15.3.5.3 Updated 

This shall be the state that is used while registered. The MS shall be ready for transactions. 

15.3.5.4 Temporary disabled 

This state shall be used after receiving a <disable> message with parameter "temporary". The only way out of the state 
shall be a <enable> message. 

1 5.3.5.5 Permanently disabled 

This state shall be used after receiving a <disable> message with parameter "permanently". There shall be no way out of 
the state using the air interface protocol as defined in the present document. 
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1 5.3.6 Service state diagram for tine TNMM-SAP 

The service state diagram for the TNMM-SAP shall be as shown in figures 15.2 to 15.5. 
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Figure 15.2: MM service state diagram (sheet 1 of 4) 
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Figure 15.3: MM service state diagram (sheet 2 of 4) 
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Figure 15.4: MM service state diagram (shieet 3 of 4) 
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Figure 15.5: MM service state diagram (sheet 4 of 4) 



ETSI 



31 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 



16 MM protocol 

16.1 Introduction 

This clause defines for the MS the TETRA MM protocol. This is the network layer protocol that shall be used to 
provide the MM service (see clause 15). This clause defines the protocol functions required for operation as an end 
system (i.e. providing service to an end user). 

This clause specifies: 

• procedures for registration and de-registration of a MS; 

• procedures for negotiating the energy saving scheme to be used; 

• procedures for moving to direct mode and returning to trunking mode operation; 

• procedures for requesting direct mode dual watch operation; and 

• procedures for attachment/detachment of group identities. 

In addition to this clause EN 300 392-7 [8] specifies security related parts of the MM protocol and EN 300 396-5 [24] 
specifies direct mode gateway related parts of the MM protocol. 

The procedures are defined in terms of: 

• interactions among peer network entities through the exchange of PDUs; 

• interactions between a network entity and a network service user through the exchange of network service 
primitives; 

• interaction between a network entity and an underlying service provider through the exchange of service 
primitives. 

The timer actions in the following procedures are defined: 

• start: the timer shall be reset and started to measure time as indicated in the timer parameter value 
(independently of the current timer count); and 

• stop: the timer shall be stopped and no further actions shall be taken against that timer any more before next 
starting of the timer. 

NOTE: This clause does not use any timer re-start where the timer is halted for a period of time and then counting 
continues without resetting the timer. 

16.2 MM procedures 
16.2.1 General 

The internal organization of the network layer including the MM entity is described in the Vh-D protocol architectures 

(see EN 300 392-1 [6], clause 6). 

The underlying services offered are those of the MLE, refer to clause 17 and EN 300 392-1 [6], clause 14. 
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1 6.2.2 Services provided by tine protocol 

The following services offered have been described in clause 15: 

• registration on user demand; 

• registration initiated by MLE (caused by roaming or migration); 

• registration requested by SwMI; 

• de-registration due to user request; 

• energy saving mode change to user request; 

• moving to direct mode and returning to trunking mode operation to user request; 

• direct mode dual watch operation to user request; and 

• attachment/detachment of group identities by user request; 

• attachment/detachment of group identities by SwMI request. 

In addition to this clause EN 300 392-7 [8] specifies security related MM services and EN 300 396-5 [24] specifies 
direct mode gateway related MM services. 

1 6.2.3 Underlying services assumed by the protocol 

On the air interface the protocol shall use the MLE as defined in clause 17. The data transferring type when sending 
MLE-UNITDATA request shall be type "acknowledged" if not defined otherwise in this clause. 

16.2.4 Services assumed from the local environment 

No specific service shall be assumed from the Lower Layer Management Entity (LLME). 

16.3 Protocol functions 

The basic functions of the protocol defined in the present document for the MS are: 

• to initiate PDU composition and decomposition; 

• to initiate header error detection; 



• 



to initiate activation of the selection of a cell sent to the MLE through an MLE- ACTIVATE request primitive 
at power up; 

to initiate a network code check from the information passed by the MLE using an MLE-LINK indication 
primitive. If a LA is a new LA, then registration may be required to be initiated by the MM through sending a 
U-LOCATION UPDATE DEMAND PDU to the infrastructure. If a network code is a new one then 
registration shall be initiated by the MM. The network may accept or reject the registration and the MM shall 
be informed by receiving a D-LOCATION UPDATE ACCEPT/REJECT PDU; 

to update the MLE with a new registered area through an MLE-UPDATE request primitive; 

to initiate handling of exceptional procedures reported by the MLE (failures to requests); 

to supply or update the SSI (ASSI or ISSI) to be used to the MLE through MLE-IDENTITIES request 
primitive. This information may be either in the D-LOCATION PROCEEDING or in the D-LOCATION 
UPDATE ACCEPT PDU received by the MM; 
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to supply or update the complete list of GSSIs to be used to the MLE through MLE-IDENTITIES request 
primitive. This information shall be either in the D-LOCATION UPDATE ACCEPT, D-ATTACH/DETACH 
GROUP IDENTITY or D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU received 
by the MM; 

to send and receive PDUs to and/or from the sub-layer MLE through MLE-UNITDATA request and indication 
primitive. The received PDUs can be handled locally by the MM or routed to the user application; 

to send and receive PDUs to and/or from the sub-layer MLE through MLE-PREPARE request and indication 

primitive; 

to initiate the update criteria with the monitoring of other possible cells using an MLE-UPDATE request 
primitive following an infrastructure request; 

to initiate detach handling through a TNMM-DEREGISTRATION request primitive from the user, the MM 
shall then send a message to the infrastructure; 

to initiate energy saving mode handling following a change requested by the user, the new value may be 
negotiated by the MM through transmitting it to the network in a energy saving mode information element. 

to allow the MLE to indicate to other layer 3 entities that MM is involved in an individually addressed 
signalling exchange with the SwMI by sending (to the MLE) an MLE-BUSY request primitive; 

to allow the MLE to indicate to other layer 3 entities that MM is no longer busy by sending an MLE-IDLE 
request primitive at the conclusion of such an exchange; 

to request the MLE to place the MS into a state of temporary disablement by sending MLE-DIS ABLE request 
primitive; 

to request the MLE to recover the MS from its state of temporary disablement by sending 
MLE-ENABLE request primitive; 

to allow the MLE to remove access to communication resources for the other layer 3 entities by sending 
MLE-CLOSE request primitive; 

to allow the MLE to provide access to communication resources for other layer 3 entities after successful 
registration and after recovery from temporary disablement by sending MLE-OPEN request primitive. 

On the infrastructure side, the MM functions should be symmetrical, except activation of the selection of a cell which 
does not exist. Figure 16.1 summarizes the MM functions. 

The different protocol procedures are shown in the present document by the primitive sequences and PDU exchanges. 
The scenarios outlined are: 

de-registration; 

energy saving mode change; 

user request registration; 

network request registration; 

MLE initiated registration; 

user request attachment/detachment of group identities; 

network request attachment/detachment of group identities; 

moving to direct mode and returning to trunking mode operation; and 

requesting direct mode dual watch operation. 
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Figure 16.1 indicates the main functions of the MM. 



MS application 




TNMM-SAP 



MM 



Activation/deactivation 



Registration/deregistration 



Attaclnment/deattaclnment 
of group identities 



Group reporting 



Energy economy mode 



DM0 dual watch 



Security 




LMM-SAP 



NOTE: Security functions are defined in EN 300 392-7 [8]. 

Figure 16.1 : MM main functions on the MS 

1 6.3.1 Activation and control of underlying MLE Service 
16.3.1.1 Activation procedure 

If the MS has its ITSI or TEI or both been permanently disabled the MS shall remain disabled at power up and shall not 
activate any of the protocol entities, refer to EN 300 392-7 [8]. The following describes the procedure for MSs that have 
not been permanently disabled; refer to figure 16.2. 
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Figure 16.2: MM Activation procedure, successful cell selection 

At power up, or similar start up such as a change of SIM card, the MM shall issue an MLE-ACTIVATE request 
primitive. The MLE-ACTIVATE request primitive shall contain a list of valid mobile network identities. 

When the MS performs initial cell selection (see clause 18.3.4.6), MM shall wait for the reception of either 
a MLE-ACTIVATE confirm or MLE-ACTIVATE indication primitive. 

Upon receipt of an MLE-ACTIVATE indication primitive, the MM entity may issue a new MLE-ACTIVATE request 
primitive with a revised list of cell selection parameters. If no new parameters for a cell selection are available MM 
shall then inform the user application with a TNMM-SERVICE indication primitive issuing that the MS is "out of 
service". 
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Upon receipt of an MLE- ACTIVATE confirm primitive, the MM entity shall check whether the selected cell requires 
registration as follows: 

a) registration mandatory: 

the MM shall inform the user application with TNMM-SERVICE indication primitive issuing that the 
MS is "in service waiting for registration". 

b) registration is not required: 

the MM shall open the communication resources to the other higher layer entities by issuing an 
MLE-OPEN request primitive to MLE which shall pass it to other entities. This MLE-OPEN request 
primitive shall be accompanied by a list of currently valid subscriber identities (ITSI, GTSI) in an 
MLE-IDENTITIES request primitive. The MM shall inform the user application with TNMM-SERVICE 
indication primitive indicating that the MS is "in service". The TNMM-SERVICE indication primitive 
shall not be issued if the MS has previously been temporarily disabled and not subsequently enabled by 
the infrastructure. 

16.3.1.2 Deactivation procedure 

This procedure shall be invoked at power down or if the ITSI is detached from the MS. The MM shall issue an 
MLE-CLOSE request primitive to MLE to indicate that access to the communication resources has been closed to the 
other higher layer entities; SNDCP and CMCE. MM shall then issue an MLE-DEACTIVATE request primitive. 

1 6.3.1 .3 Maintenance procedures 

1 6.3.1 .3.1 Report and cancel handling 

The cancel and report procedure may be implemented in the MS and if used the following shall apply. 
Incoming MLE-REPORT indication primitives should indicate the following events: 

• a PDU has been stored by the DLL ready for transmission. At this stage the transmission may be cancelled 
using a MLE-CANCEL request primitive and no information will be sent over the air interface; 

• the first transmission of whole PDU. The BS may have received the PDU, but MS has not yet received an 
acknowledgement. At this stage the layer 2 process may be stopped using a MLE-CANCEL request primitive, 
but MM cannot rely on the cancellation and may receive a response to the sent PDU; 

• a PDU has not been successfully transmitted by layer 2 Cancellation is no longer possible, but the BS may 
have received the PDU correctly and MM cannot rely on the cancellation and may receive a response to the 
sent PDU; 

• a PDU has been successfully transmitted by layer 2. Cancellation is no longer possible. 

The MLE-CANCEL request primitive can minimize the risk of adding extra load to the air interface, e.g. when a user 
application initiated registration request is buffered by the lower layers waiting for allowance to make random access 
attempt, which can take a considerable amount of time. If the user application during this waiting period changes its 
decision and wants to de-register, the application shall send a TNMM-DEREGISTRATION request primitive which 
will be converted to a MLE-CANCEL request primitive depending on the status of the transmission as stated above. 

1 6.3.1 .3.2 stealing permission and stealing repeats flag handling 

For each PDU sent by MM, stealing permission and stealing repeats flag are set to some value. The values used are 
outside of the scope of the present document. 
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16.3.1.3.3 Busy handling 



An MLE-BUSY request primitive shall be sent to the MLE by the MM when it initiates an individually addressed 
signalling exchange with the SwMI, e.g. registration, authentication, group management, etc., and an MLE-IDLE 
request primitive shall be sent to the MLE when the MM has completed any such signalling. This allows the MLE to 
indicate to other entities that MM is currently busy. MM shall also inform the state to the user application by sending 
TNMM-SERVICE indication primitive with "MM busy" or "MM idle" indication. The behaviour of the user application 
is outside the scope of the present document. However it is recommended that the user application does not initiate new 
signalling exchange (e.g. group attachment) while the MM is busy in another action. 

16.3.1.3.4 Activity handling 

An MLE- ACTIVITY request primitive with indication "stay alive" shall be sent to the MLE by the MM when it 
initiates a signalling exchange with the SwMI for which it waits for layer 3 response. An MLE-ACTIVITY request 
primitive with indication "sleep permitted" shall be sent to the MLE when the MM has completed any such signalling. 
This allows the MLE to temporarily withdraw the energy economy mode when MM is waiting for a response from the 
SwMI. 



16.4 Registration procedure 



The registration procedures are illustrated in figures 16.3 to 16.6 respectively. Registration can be initiated by the MLE, 
by the user application or it can be requested by the infrastructure. 

Security related information elements and their usage are defined in EN 300 392-7 [8]. 

A MS in the temporarily disabled state shall set the location update type information element to "Disabled MS 
updating" in all registration cases. The MS shall remain in the temporarily disabled state (i.e. access to the 
communication resources shall remain open only for the MM entity and those services in CMCE listed in the "permitted 
services" parameter of the MLE-DISABLE request primitive that was sent by MM to the MLE to initiate the 
temporarily disabled state.). The temporarily disabled state is defined in EN 300 392-7 [8]. 

MS shall assume at the start of registration to be unregistered except for forward and periodic registration, refer to 
clause 16.4.1.2. If there is no response to the registration the MS shall assume its previous state to be valid. In case the 
MS has to perform cell reselection before receiving acknowledgement to registration request, the MS shall consider 
itself unregistered and shall send a registration request on the new cell. The location update element type applied shall 
be the same as for the interrupted registration, except in case when MS was performing periodic registration; then Ms 
shall use either value "roaming location updating" or "call restoration roaming location updating" depending whether 
there is an active circuit mode call. 

The behaviour of an MS in case it has to perform cell reselection before receiving acknowledgement to other requests 
related to MM procedures (e.g. group attachment/detachment), is outside the scope of the present document. 



16.4.1 IVILE initiated registration procedure 



The MLE shall initiate normal or forward registration when cell reselection into a location area outside of the current 
registered area is indicated and the new cell requires registration. In addition, if the MS selects a cell that indicates in 
the BS service details that "System-wide services temporarily not supported" the MLE shall indicate a need for normal 
registration in case the new cell belongs to the registered area of the MS and the new cell requires registration. 

Cell reselection into a new cell shall be notified to MM by the receipt of an MLE-LINK indication primitive. The 
MLE-LINK indication primitive shall supply the MNC, MCC and the LA of the new cell. 

The registration type can be either normal, forward or periodic registration indicated by registration type parameter 
received in the MLE-LINK indication primitive from the MLE. The normal registration is described in clause 16.4.1.1, 
the forward registration in clause 16.4.1.2 and periodic registration in clause 16.4.2. Forward registration shall be 
applied only in case there is a circuit mode call active and the MS is attempting announced type 1 cell reselection. 

When BS service details change to "System-wide services supported" and the MS is temporary registered, see 
clause 16.4.8, the MLE shall indicate a need for periodic registration. 
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16.4.1.1 Normal registration 

The registration procedure can be carried out with, or without, identity exchange (see EN 300 392-1 [6], clause 9). 
Identity exchange shall be required where the MS migrates to a new TETRA network other than the home network. 

Normal registration case a) "roaming" shall be applied when the MS with the same ITSI has already successfully 
registered to the network, refer to figure 16.3. 

Normal registration case b) "migrating; MS migrates to other than its home network" shall be applied when the MNC or 
MCC of the ITSl differ from the LANC and LACC of the new cell to which the MS now registers (visited SwMl) and 
there is no valid registration of the ITSI to the new network). 

Normal registration case c) "migrating; MS migrates back to its home network" shall be applied when the MNC and 
MCC of the ITSI are the same as the LANC and LACC of the new cell to which the MS now registers (home SwMI) 
and there is no valid registration of the ITSI to the new network), refer to figure 16.3. 

Normal registration case d) "temporarily disabled MS" shall always be applied if the TEI or ITSI of the MS has been 
temporarily disabled, refer to figure 16.3. 
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NOTE: IVILE-REPORT shown in this figure applies to all scenarios where MM sends a PDU. 
Figure 16.3: MLE initiated registration in cases a), b) and d) 
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For all cases a) to d) the information element "Group report response" shall not be present in these registration PDUs. 

a) roaming: 

The MM entity shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-UNITDATA request primitive. The location update type information element in the PDU shall be 
set either to "roaming location updating", or if there was a circuit mode call active, to "call restoration 
roaming location updating". If "roaming location updating" PDU priority is set to 3 and if "call 
restoration roaming location updating" PDU priority is set to 5. Upon sending the U-LOCATION 
UPDATE DEMAND PDU the MM shall assume that group identities with parameter value "Attachment 
for next location update required" are no longer attached. If MS wishes to receive signalling on those 
group identities either the U-LOCATION UPDATE DEMAND PDU may include a request for 
attachment/detachment of those group identities in the group identity location demand information 
element or MM may later attach the groups using attach mechanism, see clausel6.8.2. The PDU may 
contain the SSI (or SSI + address extension) information elements. If present, they shall contain the ISSI 
of the MS and MNI of the MS, respectively. The PDU may contain characteristics of the MS terminal in 
the class of MS information element and may provide additional characteristics in the extended 
capabilities information element if the MS supports any of the characteristics that are declared in the 
extended capabilities information element (there is no requirement for the MS to include the extended 
capabilities element if the MS supports none of the characteristics that are declared in that information 
element).. The PDU may also contain energy economy mode information in the energy saving mode 
information element, if so the timer T352 shall be started. The MS may also request to append the new 
LA into the current RA in the request to append LA information element. The information element LA 
information shall not be present in the PDU because this is not a forward registration. The 
MLE-UNITDATA request primitive parameters shall indicate that the identity to be used shall be the 
ASSI/(V)ASSI, if one has been issued, or the ISSI in the case where an ASSI/(V)ASSI has not been 
issued. Timer T35 1 shall be started. 

NOTE 1 : If ASSI or (V)ASSI is available at layer 2, it is recommended that the MS does not reveal its true identity 
by sending ISSI in layer 3. 

b) Migrating; MS migrates to other than its home network: 

The MM entity shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-UNITDATA request primitive. The location update type information element in the PDU shall be 
set either to "migrating location updating", or if there was a circuit mode call active, to "call restoration 
migrating location updating". If "migrating location updating" PDU priority shall be set to 3 and if "call 
restoration migrating location updating" PDU priority shall be set to 5, the PDU shall include the MNI of 
the MS in the address extension information element and may include the ISSI of the MS in the SSI 
information element. This first U-LOCATION UPDATE DEMAND PDU shall not include optional 
information elements class of MS, extended capabilities, energy saving mode and group identity location 
demand. The information element LA information shall not be present in the PDU because this is not 
a forward registration. The primitive parameters shall indicate to the lower layers that the USSI of the 
MS shall be used. Timer T35 1 shall be started. 

NOTE 2: The use of the SSI information element in the U-LOCATION UPDATE DEMAND PDU is not 
recommended as it will result in fragmentation in MAC layer. 

If SwMI is ready to reject the registration at this stage it shall send D-LOCATION UPDATE REJECT 
PDU which shall include the MNI of the MS. The SSI in the layer 2 shall be the USSI. Otherwise SwMI 
shall send D-LOCATION UPDATE PROCEEDING PDU allocating (V)ASSI. 

Upon receipt of the D-LOCATION UPDATE PROCEEDING, the MM shall check whether the MCC 
and MNC, included in the address extension information element, correspond to those values held in the 
MS. If the MNC or MCC do not correspond to the transmitted values, no further action shall be taken 
against that PDU. If the MNC and MCC do correspond to the transmitted values, the MM shall extract 
the (V)ASSI from the SSI field and send this to the MLE by using MLE-IDENTITIES request primitive. 
Timer T351 shall be stopped. The MS shall immediately change to use the (V)ASSI in all subsequent 
signalling except for the layer 2 acknowledgement for the received D-LOCATION UPDATE 
PROCEEDING PDU, where the USSI shall be used. 
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The MM entity shall send a second U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-UNITDATA request primitive. This shall have PDU priority 6. The PDU shall contain the MNI of 
the MS in the address extension information element and the ISSI of the MS in the SSI information 
element. The PDU shall contain characteristics of the MS terminal in the class of MS information 
element. If the MS supports one or more of the items listed in the extended capabilities information 
element, the PDU shall also include the extended capabilities information element. The PDU may 
contain energy economy mode information in the energy saving mode information element, if so the 
timer T352 shall be started. Upon sending the U-LOCATION UPDATE DEMAND PDU the MM shall 
assume that the group identities are no more attached. If MS wishes to receive signalling on those group 
identities either the U-LOCATION UPDATE DEMAND PDU may include a request for 
attachment/detachment of those group identities in the group identity location demand information 
element or MM may later attach the groups using attach mechanism, see clause 16.8.2. The MM shall not 
request to append the new LA into the current RA in the request to append LA information element. The 
information element LA information shall not be present in the PDU because this is not a forward 
registration. The location update type information element in the PDU shall be set to demand location 
updating. The primitive parameters shall indicate that the identity to be used shall be the SSI ((V)ASSI). 
Timer T35 1 shall be started. 

c) Migrating; MS migrates back to its home network: 

The MM entity shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-UNITDATA request primitive. The location update type information element in the PDU shall be 
set either to "migrating location updating", or if there was a circuit mode call active, to "call restoration 
migrating location updating". If "migrating location updating" PDU priority shall be set to 3 and if "call 
restoration migrating location updating" PDU priority shall be set to 5. The PDU shall include the MNI 
of the MS in the address extension information element and may include the ISSI of the MS in the SSI 
information element. The PDU shall contain characteristics of the MS terminal in the class of MS 
information element. If the MS supports one or more of the items listed in the extended capabilities 
information element, the PDU shall also include the extended capabilities information element. The PDU 
may contain energy economy mode information in the energy saving mode information element, if so the 
timer T352 shall be started. Upon sending the U-LOCATION UPDATE DEMAND PDU the MM may 
assume that the group identities which have earlier been attached in the home network with parameter 
value "Attachment not needed" are attached and shall assume that all other group identities with other 
parameter values are no more attached. If MS wishes to receive signalling on those unattached group 
identities either the U-LOCATION UPDATE DEMAND PDU may include request for 
attachment/detachment of group identities in the group identity location demand information element or 
MM may later attach the groups using attach mechanism, see clause 16.8.2. The MM should not try to 
attach the group identities with parameter values "Attachment not allowed for next ITSI attach" or which 
have been permanently detached in the home network. The MS shall not request to append the new LA 
into the current RA in the request to append LA information element. The information element LA 
information shall not present in the PDU because this is not a forward registration. The primitive 
parameters shall indicate to the lower layers that the address to be appended shall be the ISSI. Timer 
T35 1 shall be started. 

d) Temporarily disabled MS: 

a), b) or c) shall apply with the location update type information element set to "Disabled MS updating". 
The MS shall remain in the temporarily disabled state (i.e. access to the communication resources shall 
remain open only for the MM entity and those services in CMCE listed in the "permitted services" 
parameter of the MLE-DIS ABLE request primitive that was sent by MM to the MLE to initiate the 
temporarily disabled state). The temporarily disabled state is defined in EN 300 392-7 [8]. In the 
temporarily disabled state the group attachments are not allowed and call restoration is not applicable. 

If SwMI accepts the registration it shall send a D-LOCATION UPDATE ACCEPT PDU. 
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For cases a), b), c) and d) :upon receipt of the D-LOCATION UPDATE ACCEPT PDU received with an 
MLE-UNITDATA indication primitive, MM shall if present, extract the MNI from the address extension information 
element and check that it is the same as MNI of the MS ITSI and, if that is the case or the MNI is not present, then the 
MM shall: 

NOTE 3: The address extension information element cannot act as complete safe guard because there is no 
information element for the IS SI in the PDU. 

• If present, extract the ASSI or (V)ASSI from the SSI field. 



• 



If the U-LOCATION UPDATE DEMAND contained a request for attachment/detachment of group identities, 
the MM shall inspect the group identity location accept information element to find out if the SwMI accepted 
them. In case the group identity location accept information element is not present in the D-LOCATION 
UPDATE ACCEPT PDU, the MS shall assume the group attachment/detachment failed. The MS shall treat 
the failure as equivalent to T353 timer expiry. If the group attachment acknowledgement does not contain 
explicit group lifetime, then the applied lifetime is outside the scope of the present document. 

• The MM shall inform the MLE of ASSI or (V)ASSI and the accepted and thus attached group identities with 
related (V)GSSIs when applicable and shall command MLE to remove detached group identities with an 
MLE-IDENTITIES request primitive, see clause 16.8. The MS shall immediately change to use the ASSI or 
(V)ASSI in layer 2 in all subsequent signalling except for the layer 2 acknowledgement for the received 
D-LOCATION UPDATE ACCEPT PDU, where the SSI used shall be the same as the layer 2 address used to 
transfer the D-LOCATION UPDATE ACCEPT PDU. 

• Timer T351 shall be stopped. 

• MM shall, if information elements are present, extract from the PDU the information concerning SCCHs and 
minimum mode (18th frame) monitoring, energy saving information, subscriber class and new registered area 
information, and inform these to the lower layers in an MLE-INFO request primitive, refer to clauses 16.7.1 
and 16.4.9. 

• If the new registered area information element is not present in the PDU, the MS shall consider the current RA 
to include only the current LA the MS just registered on with no registration timeout. 

• If the new registered area information element is present, then the new RA is that defined by the LAs in the 
New Registered Area information element and the LA timer associated with each LA shall be started. SwMI 
shall include the LA into which the registration was made in the New registered area information element. 
Refer to clause 16.4.6 for LA time-out. 

• The MS MM shall issue an MLE-UPDATE request primitive indicating a registration result of "Success" or 
"Temporary registration" and the LAs in the RA. MM shall inform the user application that the MS is ready 
for use by issuing a TNMM-REGISTRATION indication primitive containing registration and group 
attachment/detachment information. 

• Where an energy economy mode has been requested and the MS is not informed of the outcome of this request 
in the D-LOCATION UPDATE ACCEPT PDU, the information shall be conveyed in a separate 

D-MM STATUS PDU as described in clause 16.7.1. 

• For subscriber class procedures, see clause 16.4. 

For cases b) and c) (MS migration to other than its home network, or MS migrates back to its home network), the 
optional Default group attachment lifetime information element may be present in the D-LOCATION UPDATE 
ACCEPT PDU. If the element is not present, the MS shall assume the hfetime "Attachment for next ITSI- Attach 
required" to be the default lifetime. 
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If SwMI rejects the registration it shall send a D-LOCATION UPDATE REJECT PDU. Upon receipt of a 
D-LOCATION UPDATE REJECT PDU MM shall if present, extract the MNI from the address extension information 
element and check that it is the same as MNI of the MS ITSI and shall check if timers T351 or T354 are active. If either 
timer T351 or T354 is active and either the MNI is present in the PDU and matches the MNI of the MS's ITSI or the 
MNI is not present, then the MM shall: 

NOTE 4: The address extension information element cannot act as complete safe guard because there is no 
information element for the IS SI in the PDU. 

• stop timers T35 1 and T352, if started; 

• inform the user application about registration failure by issuing a TNMM-REGISTRATION indication 
primitive containing "failure" and the reject cause; 

• analyse the reject cause: 

in the event that a Congestion or Network failure is reported, MM may re-try registration after a suitable 
time or issue an MLE-UPDATE request primitive with a registration result of "cell rejection" in order 
that the MLE initiates cell reselection procedures as defined in clause 18.3.4.7; 

in the event that "LA not allowed", "Service not subscribed" or "Roaming not supported" is reported, 
MM shall issue an MLE-UPDATE request primitive with a registration result of "LA rejection" in order 
that the MLE initiates cell reselection procedures as defined in clause 18.3.4.7; 

in the event that a ITSI/ATSI unknown is reported, if the MAC header contains ASSI or (V)ASSI, the 
MS shall re-try registration using the USSI or ISSI in layer 2 depending whether the MS is registering to 
its home network. In case MS is registering to its home network, it shall perform registration as defined 
in clause 16.4.2 case b) new ITSI. In case MS is registering to foreign network, it shall perform 
registration as defined in clause 16.4.1.1 case b) migrating; MS migrates to other than its home network. 
If the MAC header contains ISSI or USSI, then: 

■ if the MS has received fewer than N35 1 registration results of type "system rejection" without 

a successful registration, MM shall issue an MLE-UPDATE request primitive with a registration 
result of "LA rejection"; or 

■ if the MS has received N35 1 registration results of type "system rejection" without a successful 
registration, MM shall issue an MLE-UPDATE request primitive with a registration result of 
"system rejection" in order that the MLE initiates cell reselection procedures as defined in 
clause 18.3.4.7; 

in the event of a Mandatory element error or Message inconsistency error is reported, the MS shall be 
allowed at least one registration re-try; 

in the event of an Illegal MS or Migration not supported is reported, then: 

■ if the MS has received fewer than N35 1 registration results of type "system rejection" without 

a successful registration, MM shall issue an MLE-UPDATE request primitive with a registration 
result of "LA rejection"; or 

■ if the MS has received N35 1 registration results of type "system rejection" without a successful 
registration, MM shall issue an MLE-UPDATE request primitive with a registration result of 
"system rejection" in order that the MLE initiates cell reselection procedures as defined in 
clause 18.3.4.7; 

the reject cause Forward registration failure shall not applicable to normal registration; 

in the event of any other registration result of type "system rejection": 

■ if the MS has received fewer than N35 1 registration results of type "system rejection" without 

a successful registration, MM shall issue an MLE-UPDATE request primitive with a registration 
result of "LA rejection"; or 
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■ if the MS has received N35 1 registration resuhs of type "system rejection" without a successful 
registration, MM shall issue an MLE-UPDATE request primitive with a registration result of 
"system rejection" in order that the MLE initiates cell reselection procedures as defined in 
clause 18.3.4.7; 

all other reject causes are outside the scope of this clause of the present document; 

in the event that the serving cell was the only cell available MM shall issue an MLE-CLOSE request 
primitive to the MLE and TNMM-SERVICE indication primitive to the TNMM-SAP indicating that the 
MS is "out of service". The MM shall consider the MS to be de-registered and hence apply the activation 
procedure as defined in clause 16.3 in order to get into service again. 

NOTE 5: When to apply the activation procedure, after no service is obtained, is outside the scope of the present 
document. 

If neither timer T351 nor T354 was active when the MS MM received the D-LOCATION UPDATE REJECT PDU, 
MM shall discard the PDU without making a response at layer 3. 

The SwMI should not cancel an existing registration for a particular ITSI if that ITSI fails a new authentication 
challenge by the SwMI. 

16.4.1.2 Forward registration 

Forward registration shall be applied in case there is a circuit mode call active and the MS is attempting announced 
type 1 cell reselection and the MS with the same ITSI has already successfully registered to the network and the cell to 
which it now registers does not belong to its current RA (home and visited SwMI). 
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Figure 16.4: MLE initiated forward registration 
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The location update type information element in the U-LOCATION UPDATE DEMAND PDU shall be set to "call 
restoration location updating". The U-LOCATION UPDATE DEMAND PDU may contain energy economy mode 
information in the energy saving mode information element, if so the timer T352 shall be started. The PDU may contain 
the SSI and address extension information elements, if present, the information elements shall contain the ISSI of the 
MS an MNI of the MS, respectively. The PDU may also contain characteristics of the MS terminal in the class of MS 
information element and may provide additional characteristics in the extended capabilities information element if the 
MS supports any of the characteristics that are declared in that information element (there is no requirement for the MS 
to include the extended capabilities element if it supports none of the characteristics that are declared in that information 
element). The MS may also request to append the new LA into the current RA in the request to append LA information 
element. The PDU shall contain the location area identification of the new cell, where to the MS is forward registering, 
in the LA information element. Upon sending the U-LOCATION UPDATE DEMAND PDU the MM shall assume that 
group identities with parameter value "Attachment for next location update required" are not attached on the new LA. If 
MS wishes to receive signalling on those group identities the U-LOCATION UPDATE DEMAND PDU shall include 
a request for attachment/detachment of those group identities in the group identity location demand information element 
or MM may later attach the groups using attach mechanism, see clause 16.8.2. The MLE-UNITDATA request primitive 
parameters shall indicate that the identity to be used shall be the ASSI/(V)ASSI, if one has been issued, or the ISSI in 
the case where an ASSI/(V)ASSI has not been issued. Timer T351 shall be started. 

NOTE 1 : If ASSI or (V)ASSI is available at layer 2, it is recommended that the MS does not reveal its true identity 
by sending ISSI in layer 3. 

"Group report response" shall not be present in forward registration PDUs. 

If the SwMI accepts the registration it shall send a D-LOCATION UPDATE ACCEPT PDU in an MLE D-NEW CELL 
PDU as defined in clause 18.3.4. 

Upon receipt of the D-LOCATION UPDATE ACCEPT PDU by the MLE-PREPARE confirm primitive the MM shall 
if present, extract the MNI from the address extension information element and check that it is the same as MNI of the 
MS ITSI and, if that is either the case or the MNI is not present, then the MM shall: 

• Extract the ASSI or (V)ASSI from the SSI field. The MS shall immediately change to use the ASSI/(V)ASSI 
in layer 2 in all subsequent signalling except for the layer 2 acknowledgement for the received D-LOCATION 
UPDATE ACCEPT PDU, where the same SSI shall be used as was used in layer 2 in the D-LOCATION 
UPDATE ACCEPT PDU. MM shall, if present, extract the MNI of the MS from the address extension 
information element. If the U-LOCATION UPDATE DEMAND contained request for attachment/detachment 
of group identities, the MM shall inspect the group identity location accept information element to find out if 
the SwMI accepted them. In case the group identity location accept information element is not present in the 
D-LOCATION UPDATE ACCEPT PDU, the MS shall assume the group attachment/detachment failed. The 
MS shall treat the failure as equivalent to T353 timer expiry. If the group attachment acknowledgement does 
not contain explicit group lifetime, then the applied lifetime is outside the scope of the present document. MM 
shall inform the MLE of ASSI or (V)ASSI and accepted and thus attached group identities and related 
(V)GSSI, when applicable with an MLE-IDENTITIES request primitive. MM shall, if information element is 
present, extract from the PDU the information concerning new registered area information, and inform these to 
the lower layers in an MLE-INFO request primitive. 

NOTE 2: The address extension information element cannot act as complete safe guard because there is no 
information element for the ISSI in the PDU. 

• If the new registered area information element is not present in the PDU, the MS shall consider the current RA 
to include only the current LA the MS just registered on with no registration timeout. 

• If the new registered area information element is present, then the new RA is that defined by the LA's in the 
New registered area information element and the LA timer associated with each new LA shall be started. 

NOTE 3: The LA from which the MS is roaming is not part of the new RA unless that LA is included in the New 
registered area information element. 

• Timer T351 shall be stopped. MM shall, if information elements are present, extract from the PDU the 
information concerning SCCH, energy saving information (economy mode, and minimum mode (18th frame) 
monitoring), subscriber class, if present, and inform these to the lower layers in an MLE-INFO request 
primitive, refer to clauses 16.7.1 and 16.4.9. 

• For subscriber class procedures see clause 16.4. 
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The MS MM shall issue an MLE-UPDATE request primitive indicating a registration result of "Success" or 
"Temporary registration" and the LAs in the RA. MM shall inform the user application that the MS is ready for use by 
issuing a TNMM-REGISTRATION indication primitive containing registration and group attachment/detachment 
information. Where an energy economy mode has been requested and the MS is not informed of the outcome of this 
request in the D-LOCATION UPDATE ACCEPT PDU, the information shall be conveyed in a separate 
D-MM STATUS PDU as described in clause 16.7.1. 

If the SwMI rejects the registration it shall send a D-LOCATION UPDATE REJECT PDU. Upon receipt of 
a D-LOCATION UPDATE REJECT, MM shall if present, extract the MNI from the address extension information 
element and check that it is the same as MNI of the MS ITSI and shall check if timers T351 or T354 are active. If either 
timer T351 or T354 is active and either the MNI is present in the PDU and matches the MNI of the MS's ITSI or the 
MNI is not present, then the MM shall: 

NOTE 4: The address extension information element cannot act as complete safe guard because there is no 
information element for the IS SI in the PDU. 

• stop timers T35 1 and T352, if started; 

• inform the user application about registration failure by issuing a TNMM-REGISTRATION indication 
primitive containing "failure" and the reject cause; 

• remain registered in the current cell with previous ASSI, (V)ASSI, GSSIs and (V)GSSIs as appropriate. 

• analyse the reject cause: 

in the event that a "forward registration failure" is reported, MM shall issue an MLE-UPDATE request 
primitive with a registration result of "forward registration failure", refer to clause 17.3.9, in order that 
the MLE initiates cell reselection procedures as defined in clause 18.3.4.7. 

in the event that a LA unknown, MM shall issue an MLE-UPDATE request primitive with a registration 
result of "LA rejection" in order that the MLE initiates cell reselection procedures as defined in 

clause 18.3.4.7. 

all other reject causes are analysed and acted similarly as with normal registration (clause 16.4.1.1). 

If neither timer T351 nor T354 was active when the MS MM received the D-LOCATION UPDATE PDU, MM shall 
discard the PDU without making a response at layer 3. 

The SwMI should not cancel an existing registration for a particular ITSI if that ITSI fails a new authentication 
challenge by the SwMI. 

In the temporary disabled state call restoration and forward registration are applicable only in the case of ambience 
listening. 

16.4.2 User application initiated registration procedure 

User application initiated registration shall be available whenever the MS is camped on a cell, i.e. has received TNMM- 
SERVICE indication primitive stating that the MS is "in service waiting for registration" or "in service". It shall be 
applied whenever an identity is attached to the MS. The user application initiated registration can be used at power up 
and at any time provided that an ITSI is available either within the MS, and shall be supplied with the 
TNMM-REGISTRATION request primitive, see figure 16.5. 

In case the status of the BS changes from "system wide services temporarily not supported " to "normal mode" and the 
MS has a temporary registration to the cell, the MLE shall indicate a need for periodic registration to MM by sending an 
MLE-LINK indication primitive. In such a case or if a LA timer expires and the LA is the current LA, the MM shall 
inform user application by sending a TNMM-REGISTRATION indication primitive with registration parameter set to 
"LA registration expired" and LA parameter to the current LA so that the application could initiate registration in a 
suitable time e.g. after completing on-going call. 
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Figure 16.5: User application initiated registration in cases a) and b) 

MM shall check whether the TNMM-REGISTRATION request primitive contains a request to perform a periodic 
registration or to select a specified MCC and MNC and possible LA. In case the TNMM-REGISTRATION request 
primitive is not a periodic registration request, MM shall send the preferred network / LA list in an MLE-LINK request 
primitive to MLE and shall wait for MLE-LINK indication primitive. If MM receives MLE- ACTIVATE indication 
primitive from MLE because MLE is not able to select the requested MCC, MNC or LA, MM shall inform the user 
application by issuing a TNMM-REGISTRATION confirm primitive indicating "no preferred cell found". The user 
appUcation may then provide new MCC, MNC and/or LA information to MM using a TNMM-REGISTRATION 
request primitive. 

If the MS is in state "in service" and the user application was not requesting periodic registration, MM shall wait for an 
MLE-LINK indication primitive from the MLE and perform registration as specified in clause 16.4. L 

If the MS is in state "in service waiting for registration", MM shall send an MLE-LINK request primitive to MLE and 
wait for MLE-LINK indication primitive. For a periodic registration request or after receiving an MLE-LINK indication 
primitive from the MLE, MM shall ascertain whether there is a new ITSI being attached as follows: 

• case a) "no new ITSI" shall be applied when the MS with the same ITSI has already successfully registered to 
the network (home and visited SwMI); 

• case b) "new ITSI" shall be applied at power up registration or when there is no valid registration of the ITSI 
to the network and the MNC and MCC of the ITSI are the same as the LANC and LACC of the cell the MS is 
camped on (home SwMI); 

• case c) "new un-exchanged ITSI" shall be applied at power up registration or when there is no valid 
registration of the ITSI to the network and the MNC or MCC of the ITSI differ from the LANC or LACC of 
the cell the MS is camped on (visited SwMI). 
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In addition a temporarily disabled MS shall follow case d). 

a) no new ITSI: 

MM shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an MLE-UNITDATA 
request primitive. This shall have PDU priority 3. 

The location update type information element in the PDU shall be set to "periodic location updating" . 

The PDU may contain the SSI and address extension information elements, if present, the information 
elements shall contain the ISSI of the MS and MNI of the MS, respectively. The PDU may also contain 
the class of MS information element, and may provide additional characteristics in the extended 
capabilities information element if the MS supports any of the characteristics that are declared in the 
extended capabilities information element (there is no requirement for the MS to include the extended 
capabilities element if the MS supports none of the characteristics that are declared in that information 
element). The PDU may include the energy saving mode information element, if so the timer T352 shall 
be started. Upon sending the U-LOCATION UPDATE DEMAND PDU the MM shall assume that group 
identities with parameter value "Attachment for next location update required" are no more attached. If 
MS wishes to receive signalling on those group identities either the U-LOCATION UPDATE DEMAND 
PDU may include request for attachment of those group identities in the group identity location demand 
information element or MM may later attach the groups using attach mechanism, see clause 16.8.2. The 
MLE-UNITDATA request primitive parameters shall indicate that the identity to be used shall be the 
ASSI/(V)ASSI, if one has been issued, or the ISSI in the case where an ASSI/(V)ASSI has not been 
issued. Timer T35 1 shall be started. 

NOTE 1 : If ASSI or (V)ASSI is available at layer 2, it is recommended that the MS does not reveal its true identity 
by sending ISSI in layer 3. 

b) new ITSI: 

in this case at the beginning the communication resources are closed. The MM shall register with the 
home network using ISSI. MM shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with 
an MLE-UNITDATA request primitive. This shall have PDU priority 6. The location update type 
information element in the PDU shall be set to "ITSI attach". The PDU shall also contain the 
characteristics of the MS terminal in the class of MS information element If the MS supports one or more 
of the items listed in the extended capabilities information element, the PDU shall also include the 
extended capabilities information element.. The PDU may contain the SSI and address extension 
information elements, if present, the information elements shall contain the ISSI of the MS and MNI of 
the MS, respectively. The PDU may also contain energy economy mode information in the energy saving 
mode information element, if so the timer T352 shall be started. Upon sending the U-LOCATION 
UPDATE DEMAND PDU the MM may assume that group identities which have earlier been attached in 
the home network with parameter value "Attachment not needed" are attached and shall assume that all 
other group identities are no more attached. If MS wishes to receive signalling on the unattached group 
identities either the U-LOCATION UPDATE DEMAND PDU may include request for 
attachment/detachment of those group identities in the group identity location demand information 
element or MM may later attach the groups using attach mechanism, see clause 16.8.2. The MM should 
not try to attach the group identities with parameter values "Attachment not allowed for next ITSI attach" 
or which have been permanently detached in the home network. The MS shall not request to append the 
new LA into the current RA in the request to append LA information element. The information element 
LA information is not present in the PDU because this is not a forward registration. The primitive 
parameters shall indicate that the identity to be appended by the MAC shall be the SSI (ISSI). Timer 
T35 1 shall be started; 
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c) new un-exchanged ITSI: 



in this case at the beginning the communication resources are closed. The MM shall register on a visited 
network using identity exchange. The MM entity shall send a U-LOCATION UPDATE DEMAND PDU 
with PDU priority 3 to the MLE with an MLE-UNITDATA request primitive and issue an MLE-BUSY 
request primitive to the MLE. The location update type information element in the PDU shall be set to 
"migrating location updating". The PDU shall include the MNI of the MS in the address extension 
information element and may include the ISSI of the MS in the SSI information element. There shall be 
no optional information elements class of MS, extended capabilities, energy saving mode and group 
identity location demand in the PDU because they shall be present in the second U-LOCATION 
UPDATE DEMAND PDU, if needed. The information element LA information shall not be present in 
the PDU because this is not a forward registration. The primitive parameters shall indicate to the lower 
layers that the USSI of the MS shall be used. Timer T351 shall be started; 

NOTE 2: The use of the SSI information element in the U-LOCATION UPDATE DEMAND PDU is not 
recommended as it will result in fragmentation in MAC layer. 

if SwMI is ready to reject the registration at this stage it shall send D-LOCATION UPDATE REJECT 
PDU which shall include the MNI of the MS. The SSI in the layer 2 shall be the USSI. Otherwise SwMI 
shall send D-LOCATION UPDATE PROCEEDING PDU allocating (V)ASSI; 

upon receipt of the D-LOCATION UPDATE PROCEEDING PDU, the MM shall if present, extract the 
MNI from the address extension information element and check that it is the same as MNI of the MS 
ITSI and, if that is either the case or the MNI is not present, then MM shall: 

extract the (V)ASSI from the SSI field and send this to the MLE by using MLE-IDENTITIES 
request primitive. The MS shall immediately change to use the (V)ASSI in all subsequent 
signalling except for the layer 2 acknowledgement for the received D-LOCATION UPDATE 
PROCEEDING PDU, where the USSI shall be used; 

■ stop timer T351; 

■ as the message is a response to a request made using the USSI, MM shall check that the MCC and 
the MNC included in the address extension information element, correspond to the MNI of the MS. 
This shall be used to ensure that if two mobiles request registrations using the same USSI that MM 
can distinguish between them: 

if the MNIs do not match no action shall be taken; 

if the MCC and the MNC do correspond the transmitted values, the MM entity shall reply 
with a second U-LOCATION UPDATE DEMAND PDU containing the MNI of the MS in 
the address extension information element and ISSI of the MS in the SSI information 
element, thus comprising the full ITSI to the MLE with an MLE-UNITDATA request 
primitive. The PDU shall also contain the class of MS information element. If the MS 
supports one or more of the items listed in the extended capabilities information element, the 
PDU shall also include the extended capabilities information element. The PDU may also 
contain economy mode information in the energy saving mode information element, if so the 
timer T352 shall be started. Upon sending the U-LOCATION UPDATE DEMAND PDU the 
MM shall assume that all group identities are no more attached. If MS wishes to receive 
signalling on those unattached group identities either the U-LOCATION UPDATE 
DEMAND PDU may include request for attachment/detachment of group identities in the 
group identity location demand information element or MM may later attach the groups using 
attach mechanism, see clause 16.8.2. The MS shall not request to append the new LA into the 
current RA in the request to append LA information element. The information element LA 
information is not present in the PDU because this is not a forward registration. This shall 
have PDU priority 6. The location update type information element in the PDU shall be set to 
"demand location updating". The primitive parameters shall indicate that the address to be 
appended by the MAC shall be the SSI ((V)ASSI). Timer T351 shall be started. 
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d) Temporarily disabled MS: 



a), b) or c) shall apply with the location update type set to "Disabled MS updating" but there shall be no 
group attachment or reporting signalling. The MS shall remain in the temporarily disabled state 
(i.e. access to the communication resources shall remain open only for the MM entity and those services 
in CMCE listed in the "permitted services" parameter of the MLE-DISABLE request primitive that was 
sent by MM to the MLE to initiate the temporarily disabled state). The temporarily disabled state is 
defined in EN 300 392-7 [8]. 

If SwMI accepts the registration it shall send a D-LOCATION UPDATE ACCEPT PDU. 

For cases a), b), c) and d) upon receipt of the D-LOCATION UPDATE ACCEPT PDU, which shall be received with an 
MLE-UNITDATA indication primitive, MM shall, if present, extract the MNI of the MS from the address extension 
information element and check that it is the same as MNI of the MS ITSI and, if that is the case or the MNI is not 
present, then the MM shall: 

NOTE 3: The address extension information element cannot act as safe guard because there is no information 
element for the ISSI in the PDU. 

• stop timer T351; 

• extract any ASSI or (V)ASSI from the SSI field. If the U-LOCATION UPDATE DEMAND PDU contained 
request for attachment/detachment of group identities, the MM shall inspect the group identity location accept 
information element to find out if the SwMI accepted them. In case the group identity location accept 
information element is not present in the D-LOCATION UPDATE ACCEPT PDU, the MS shall assume the 
group attachment/detachment failed. The MS shall treat the failure as equivalent to T353 timer expiry. If the 
group attachment acknowledgement does not contain explicit group lifetime, then the applied lifetime is 
outside the scope of the present document. MM shall inform the MLE of ASSI or (V)ASSI and attached group 
identities with related (V)GSSIs when applicable with an MLE-IDENTITIES request primitive, see 

clause 16.8. The MS shall immediately change to use the ASSI or (V)ASSI in layer 2 in all subsequent 
signalling except for the layer 2 acknowledgement for the received D-LOCATION UPDATE ACCEPT PDU, 
where the SSI used shall be the same as the layer 2 address used to transfer the D-LOCATION UPDATE 
ACCEPT PDU; 

• extract from the PDU, if information elements are present, the information concerning SCCHs and minimum 
mode (18* frame) monitoring, energy saving information, subscriber class and new registered area and pass 
these to the lower layers in an MLE-INFO request primitive, refer to clauses 16.7. 1 and 16.4.9. If the new 
registered area information element is not present in the PDU, the MS shall consider the current RA to include 
only the current LA the MS just registered on with no registration timeout. If the new registered area 
information element is present, then the new RA is that defined by the LAs in the New registered area 
information element and the LA timer associated with each new LA shall be started (if applicable; i.e. if the 
LA Timer value is not 1 1 12). SwMI shall include the LA into which registration was made in the New 
registered area information element. The MS MM shall issue an MLE-UPDATE request primitive indicating a 
registration result of "Success" or "Temporary registration" and the LAs in the RA. MM shall inform the user 
application that the MS is ready for use by issuing a TNMM-REGISTRATION confirm primitive indicating 
"success" and containing registration and group attachment/detachment information. Where an energy 
economy mode has been requested and the MS is not informed of the outcome of this request in the 
D-LOCATION UPDATE ACCEPT PDU, the information shall be conveyed in a separate D-MM STATUS 
PDU as described in clause 16.7.1; 

• if registration is successful and communication resources were closed, then the MM shall open the 
communication resources to the other higher layer entities by issuing an MLE-OPEN request primitive. The 
MM shall inform the user application with TNMM-SERVICE indication primitive issuing that the MS is in 
service unless the MS has previously been temporarily disabled and not subsequently enabled by the 
infrastructure. 

In cases b) (new ITSI) and c) (new unexchanged ITSI) the D-LOCATION UPDATE ACCEPT PDU may contain the 
optional Default group attachment lifetime information element. If the element is not present, the MS shall assume the 
lifetime "Attachment for next ITSI- Attach required" to be the default lifetime. If the SwMI rejects the registration it 
shall send a D-LOCATION UPDATE REJECT PDU. 
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Upon receipt of the D-LOCATION UPDATE REJECT PDU, MM shall, if present, extract the MNI from the address 
extension information element and check that it is the same as MNI of the MS ITSI and shall check if timers T351 or 
T354 are active. If either timer T35 1 or T354 is active and either the MNI is present in the PDU and matches the MNI 
of the MS's ITSI or the MNI is not present, then MM shall: 

NOTE 4: The address extension information element cannot act as complete safe guard because there is no 
information element for the IS SI in the PDU. 

• stop timers T35 1 and T352, if started; 

• inform the user application about registration failure by issuing a TNMM-REGISTRATION indication 
primitive containing "failure" and the reject cause; 

• analyse the reject cause and act similarly as in normal registration, see clause 16.4.1.1. 

• further registration requests can be made in response to the receipt of further TNMM-REGISTRATION 
requests primitive from the user application, once a new cell has been selected. In the event that the serving 
cell was the only cell available, MM shall issue an MLE-CLOSE request primitive to the MLE and 
TNMM-SERVICE indication primitive to the TNMM-SAP indicating that the MS is "out of service". The MM 
shall consider the MS to be de-registered and hence apply the activation procedure as defined in clause 16.3 in 
order to get into service again. 

NOTE 5: When to apply the activation procedure, after no service is obtained is outside the scope of the present 
document. 

If neither timer T351 nor T354 was active when the MS MM received the D-LOCATION UPDATE PDU, MM shall 
discard the PDU without making a response at layer 3. 

The SwMI should not cancel an existing registration for a particular ITSI if that ITSI fails a new authentication 
challenge by the SwMI. 

16.4.3 Infrastructure initiated registration procedure 
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MM 
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NOTE: Infrastructure initiated registration is carried out following information given by the MLE through an 
MLE-UNITDATA indication primitive. 

Figure 16.6: Infrastructure initiated registration 

The SwMI may initiate registration at any time by sending a D-LOCATION UPDATE COMMAND PDU, which may 
contain a group report request. 
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Upon receipt of the D-LOCATION UPDATE COMMAND PDU, the MM shall if present, extract the MNI from the 
address extension information element and check that it is the same as MNI of the MS ITSI and, if that is either the case 
or the MNI is not present, then MM shall: 

• send a U-LOCATION UPDATE DEMAND PDU which shall contain the MNI of the MS in the address 
extension information element and the ISSI of the MS in the SSI information element, thus providing the true 
ITSI. This shall have PDU priority 6. The location update type information element in the PDU shall be set to 
"demand location updating" or "disabled MS updating" depending whether the MS is enabled or disabled. The 
MLE-UNITDATA request primitive parameters shall indicate that the identity to be used shall be the 
ASSI/(V)ASSI, if one has been issued, or the ISSI in the case where an ASSI/(V)ASSI has not been issued; 

• upon receipt of the D-LOCATION UPDATE COMMAND PDU including a group report request from the 
MLE, the MM shall regard all the group identities no more attached. If the MS wishes to receive signalling on 
those group identities, the MM may include group attachments to the U-LOCATION UPDATE DEMAND 
PDU or re-attach all the groups using U-ATTACH/DETACH GROUP IDENTITY PDUs. If the MS has no 
groups to attach, it shall send U-LOCATION UPDATE DEMAND PDU containing a group report response 
information element indicating "group report complete". When sending the first group attachment, either in 
U-LOCATION UPDATE DEMAND PDU or U-ATTACH/DETACH GROUP IDENTITY PDU, the group 
identity attach/detach mode information element shall be set to "detach all currently attached group identities 
and attach group identities defined in the group identity.." and the group identity report information element to 
"not report request". If all the reported groups are sent in this one PDU it shall contain a group report response 
information element indicating "group report complete", or otherwise not include this information element. 
The PDU priority shall be set to 3. Timer T353 shall be started. For further discussion of the use of the 
U-ATTACH/DETACH GROUP IDENTITY PDU in this context see clause 16.8.3; 

• upon receipt of the D-LOCATION UPDATE COMMAND PDU without a group report request, the MM shall 
assume that group identities with parameter value "Attachment for next location update required" are no more 
attached. If MS wishes to receive signalling on those group identities either the U-LOCATION UPDATE 
DEMAND PDU may include request for attachment of those group identities in the group identity location 
demand information element or MM may later attach the groups using attach mechanism, see clause 16.8.2; 



• 



the U-LOCATION UPDATE DEMAND PDU shall contain the class of MS element and if the MS supports 
one or more of the items listed in the extended capabilities information element, the PDU shall also include the 
extended capabilities information element; 

• the U-LOCATION UPDATE DEMAND PDU shall contain economy mode information in the energy saving 
mode information element if energy saving is activated, if so timer T352 shall be started; 

• the MS shall not request to append the new LA into the current RA in the request to append LA information 
element. The information element LA information shall not be present in the PDU because this is not a 
forward registration; 

• timer T35 1 shall be started. 

Upon receipt of the D-LOCATION UPDATE ACCEPT PDU MM shall, if present, extract the MNI from the address 
extension information element and check that it is the same as MNI of the MS ITSI and, if that is either the case or the 
MNI is not present, then MM shall: 

• extract any ASSI or (V)ASSI from the SSI field. The MS shall immediately change to use the ASSI/(V)ASSI 
in layer 2 in all subsequent signalling except for the layer 2 acknowledgement for the received D-LOCATION 
UPDATE ACCEPT PDU, where the same SSI shall be used as was used in layer 2 in the D-LOCATION 
UPDATE ACCEPT PDU; 
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• if the U-LOCATION UPDATE DEMAND PDU contained request for attachment/detachment of group 
identities, the MM shall inspect the group identity location accept information element to find out if the SwMI 
accepted them. In case the group identity location accept information element is not present in the 
D-LOCATION UPDATE ACCEPT PDU, the MS shall assume the group attachment/detachment failed. The 
MS shall treat the failure as equivalent to T353 timer expiry. If the group attachment acknowledgement does 
not contain explicit group lifetime, then the applied lifetime is outside the scope of the present document. MM 
shall inform the MLE of ASSI or V(ASSI) and accepted and thus attached group identities and related 
(V)GSSIs with an MLE-IDENTITIES request primitive, see clause 16.8. The MS shall immediately change to 
use the ASSI or (V)ASSI in all subsequent signalling except for the layer 2 acknowledgement for the received 
D-LOCATION UPDATE ACCEPT PDU, where the SSI used shall be the same as in D-LOCATION 
UPDATE ACCEPT PDU; 

• stop timer T351; 

• MM shall, if information elements are present, extract from the PDU the information concerning SCCHs and 
minimum mode (18th frame) monitoring, energy saving information, subscriber class and new registered area 
information and inform these to the lower layers in an MLE-INFO request primitive, refer to clause 16.7.1 and 
16.4.9. If the new registered area information element is not present in the PDU, the MS shall consider the 
current RA to include only the current LA the MS just registered on with no registration timeout. If the new 
registered area information element is present, then the new RA is that defined by the LAs in the New 
registered area information element and the LA timer associated with each LA shall be started. The LA into 
which the registration was made shall be included in the New registered area information element; 

• the MS MM shall issue an MLE-UPDATE request primitive indicating a registration result of "Success" or 
"Temporary registration" and the LAs in the RA. MM shall inform the user application about infrastructure 
initiated registration by issuing a TNMM-REGISTRATION indication primitive containing registration and 
group attachment/detachment information; 

• if the SwMI rejects the registration it shall send a D-LOCATION UPDATE REJECT PDU. 

Upon receipt of a D-LOCATION UPDATE REJECT PDU, MM shall, if present, extract the MNI from the address 
extension information element and check that it is the same as MNI of the MS ITSI and shall check if timers T351 or 
T354 are active. If either timer T35 1 or T354 is active and either the MNI is present in the PDU and matches the MNI 
of the MS's ITSI, or the MNI is not present, then MM shall: 

NOTE 1 : The address extension information element cannot act as complete safe guard because there is no 
information element for the IS SI in the PDU. 

• stop and reset timer T35 1 and T352, if started; 

• inform the user application about registration failure by issuing a TNMM-REGISTRATION indication 
primitive containing "failure" and the reject cause; 

• analyse the reject cause and act similarly as in normal registration, see clause 16.4.1.1; 

• in the event that the serving cell was the only cell available, MM shall issue an MLE-CLOSE request primitive 
to the MLE and TNMM-SERVICE indication primitive to the TNMM-SAP indicating that the MS is "out of 
service". The MM shall consider the MS to be de-registered and hence apply the activation procedure as 
defined in clause 16.3 in order to get into service again. 

NOTE 2: When to apply the activation procedure after no service is obtained is outside the scope of the present 
document. 

If neither timer T351 nor T354 was active when the MS MM received the D-LOCATION UPDATE PDU, MM shall 
discard the PDU without making a response at layer 3. 

The SwMI should not cancel an existing registration for a particular ITSI if that ITSI fails a new authentication 
challenge by the SwMI. 
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16.4.4 Colliding registrations 



In the event that the MS MM requests registration at the same time that the infrastructure demands that the MS MM 
registers, the MS MM should respond to the D-LOCATION UPDATE COMMAND PDU using the procedure defined 
in clause 16.4.3. On successful outcome, MM shall inform the user application with a TNMM-REGISTRATION 
indication primitive containing registration and group attachment/detachment information. 

16.4.5 Expiry of timer T351 

This timer is intended to control how often an MS may try to register to a BS. On the expiry of timer T351, if it is still 
possible to solely cancel the outstanding PDU according to clause 16.3.1.3, MM shall issue an MLE-CANCEL request 
primitive with the handle of the transmission request it corresponds to. 

If it is no longer possible to solely cancel the outstanding PDU according to clause 16.3.1.3, MM may issue a U-ITSI 
DETACH PDU using the de-registration procedures described in clause 16.6 or resend the U-LOCATION UPDATE 
DEMAND PDU using the procedures described in clauses 16.4.1 and 16. 4.2. The MS may wish to select a new serving 
cell before further registration attempts should be made. 

1 6.4.6 Expiry of LA timers 

The LA timer is intended to clear out LAs from the current RA. LA timer shall be mandatory for MS. If SwMI utilizes 
optional LA timer and it expires in the SwMI it may no more page the MS on that LA. The optional LA timer in SwMI 
should have a longer timeout value that the value attached to the MS. If a LA timer expires and the LA is not the current 
LA, then the LA shall be removed from the current RA in the MS and the MM shall issue an MLE-UPDATE request 
primitive to the MLE containing the valid LAs of the RA. If a LA timer expires and the LA is the current LA, MM shall 
inform user application by sending an TNMM-REGISTRATION indication primitive with registration parameter set to 
"LA registration expired" and LA parameter to the current LA so that the application could initiate registration in a 
suitable time e.g. after completing on-going call as defined in clause 16.4.2 a). 

1 6.4.7 Lifetime of ASSI/(V)ASSI 

Only one ahas SSI (ASSI or (V)ASSI) shall be vaHd per ITSI at one time. When the SwMI allocates a new ASSI or 
VASSI to MS (ITSI), the previous ASSI or (V)ASSI becomes invalid. 

If SwMI allocates ISSI of the MS as ASSI, the previous ASSI, if any, becomes invalid. 

Once ASSI or (V)ASSI has been allocated, MS shall use it as defined in clause 23.4.1.2.1 and 23.4.1.2.2. Even if ASSI 
has been allocated, SwMI may send PDUs using ISSI in home network (refer to clause 23.4.1.2.1, note 4) in which case 
the layer 2 acknowledgement sent by MS shall contain ISSI. 

1 6.4.7.1 ASSI/(V)ASSI validity at migration 

The ASSI/(V)ASSI is vaHd only within the SwMI which allocated it. When MS migrates (i.e. MS sends location update 
with type "migrating location updating" or "call restoration migrating location updating") the previous ASSI/(V)ASSI 
becomes invalid and the migrated to SwMI shall allocate a new (V)ASSI or may allocate an ASSI as appropriate. 

1 6.4.7.2 ASSI/(V)ASSI validity by MS initiative 

Whenever MS makes an "ITSI Attach" registration attempt (either successful or unsuccessful), the current ASSI, if any, 
becomes invalid. Whenever MS makes de-registration (sends U-ITSI DETACH PDU), the current ASSI/(V)ASSI, if 
any, becomes invalid. 
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1 6.4.7.3 ASSI/(V)ASSI validity at registration rejection 

If SwMI rejects the registration attempt either with reason "Migration not supported", "ITSI/ATSI unknown" or "Illegal 
MS", the current ASSI/(V)ASSI, if any, shall become invalid. With any other reject reason the ASSI/(V)ASSI remains 
valid. 

NOTE 1: It is useful not to withdraw the ASSI / (V)ASSI in every case when registration is rejected. For example 
in case the SwMI rejects the registration attempt because the LA is not allowed for the MS, the MS may 
send next registration (to some other LA) using the ASSI/(V)ASSI and thus not revealing its own identity 
(ISSI). 

However, in case SwMI wants to reject visiting MS permanently the (V)ASSI shall be withdrawn. 

NOTE 2: There are no means for SwMI to withdraw the ASSI explicitly within registration rejection because 
D-LOCATION UPDATE REJECT PDU does not contain ASSI/(V)ASSI information element. 

1 6.4.8 Temporary registration 

In case the status of the BS changes from "normal mode" to "system wide services temporarily not supported " the MSs 
which have already registered there stay normally registered (no action needed). 

In case MS registers to a BS which is in state "system wide services temporarily not supported" and gets a registration 
accepted response with status "Temporary registration", the MS shall consider its registration to be temporarily accepted 
in the system. The MM shall pass this "Temporary registration" information to MLE within "Registration status" 
parameter in MLE-UPDATE request primitive. 

NOTE 1: In "system wide services temporarily not supported " state, the SwMI may either accept the registration 
normally or use the "temporary registration" acknowledgement. 

In case the status of the BS changes from "system wide services temporarily not supported " to "normal mode" the MSs 
which have received a "Temporary registration" response have to register again (with type "periodic location 
updating"). The MLE shall detect the change to normal mode and shall indicate the need for periodic registration to 
MM by sending MLE-LINK indication primitive. Those MSs that have received a normal registration accept 
acknowledgement shall not register again. 

In case MS, which has received a "Temporary registration" acknowledgement, makes a cell reselection it has to register 
to the new cell even if the cell belongs to the Registered area of the MS. In this case MLE shall indicate the need for 
registration to MM by sending MLE-LINK indication primitive. 

NOTE 2: SwMI should use the "Temporary registration" acknowledge only in case the BS is in state "system wide 
services temporarily not supported". 



1 6.4.9 Subscriber class procedures 



Upon reception of a D-LOCATION UPDATE ACCEPT PDU which contains the subscriber class information element 
the MM shall: 

• if a network provides a subscriber class profile in the subscriber class information element, this overrides any 
previous subscriber class information previously supplied for this network (at subscription or earlier 
registration) and the MS will inform this to MLE in an MLE-INFO request primitive as defined registration 
protocols; 

• if the home network provides no subscriber class information in a subscriber class information element, the 
MS will use the subscriber class profile allocated at subscription; 

• if a visited network provides no subscriber class information in a subscriber class information element, the MS 
shall assume that all subscriber classes are vaUd. 

NOTE: A subscriber class profile is valid only within the network which allocated it. 
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Upon receiving MLE-INFO indication primitive indicating no match between the subscriber class being broadcast by 
the SwMI and the subscriber class of the MS, the MM shall respond to all SwMI initiated procedures normally but shall 
restrict the MS initiated requests so that only the next procedures are allowed: 

• location updating; 

• de-registration; 

• security related procedures described in EN 300 392-7 [8]. 

All the other MS initiated procedures are rejected and MM shall send a failure report to the SAP and the user 
application should assume that the requested service has failed. 

1 6.4.1 Frequency band capability procedures 

After reception of a D-LOCATION UPDATE ACCEPT PDU the MS may send a U-MM STATUS PDU carrying 
a U-MS FREQUENCY BANDS INFORMATION PDU to inform which frequency bands it supports. 

The SwMI may at any time send a D-MM STATUS PDU carrying a D-MS FREQUENCY BANDS REQUEST PDU. 
When receiving this PDU the MS should respond with sending a U-MM STATUS PDU carrying 
a U-MS FREQUENCY BANDS INFORMATION PDU to inform which frequency bands it supports. In addition MS 
should re-send the U-MS FREQUENCY BANDS INFORMATION PDU at the occasions specified in the "Re-send 
interval" element of the D-MS FREQUENCY BANDS REQUEST PDU. 

The frequency of the lower and upper edge carrier shall be defined by the following information elements: 

• lower/upper edge carrier; 

• lower/upper edge frequency band; 

• duplex spacing; 

• reverse operation. 

The upper/lower edge frequency band field shall map to a specific frequency which shall map to a defined base 
frequency (in MHz) for the carrier numbering scheme. The lower/upper edge carrier field shall indicate the carrier 
frequency relative to the base frequency defined by the corresponding frequency band field. The frequency so defined 
shall be the approximate downlink frequency of the lower/upper carrier. This calculation shall be summarized by the 
following equation: 

• downlink lower/upper edge carrier frequency = base frequency + (upper/lower edge carrier * 25 kHz). 

The uplink frequency of the lower/upper edge carrier shall be determined using the duplex spacing and reverse 
operation fields. The duplex spacing field shall map to a defined duplex spacing (in MHz) for the carrier numbering 
scheme. The duplex spacing shall be dependent on the frequency band element. The reverse operation field shall 
indicate whether to add or subtract the duplex spacing to arrive at the uplink frequency of the main carrier. If normal 
operation, the duplex spacing shall be subtracted. If reverse operation, the duplex spacing shall be added. This 
calculation is summarized by the following equations: 

• normal operation: 

uplink upper/lower edge carrier frequency = downlink main carrier frequency - duplex spacing. 

• reverse operation: 

uplink upper/lower edge carrier frequency = downlink main carrier frequency + duplex spacing. 

The mapping of the frequency band field values to actual base frequencies and the duplex spacing field values to actual 
duplex frequency spacing are defined in annex F. 

NOTE 1 : These rules for calculation of uplink and downlink carrier frequency are also used for calculation of the 
carrier frequency in clause 21 with an exception of the offset. 

NOTE 2: An MS may support a frequency range which may be larger or smaller than the actual frequency 
allocation defines in each country. 
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SwMI actions due to this information are outside the scope of the present document. 



1 6.4.1 1 Air to ground reporting procedure 



The SwMI may at any time send a D-MM STATUS PDU carrying a D-DISTANCE REPORTING REQUEST PDU. If 
the MS supports this optional procedure it shall upon reception of the D-DISTANCE REPORTING REQUEST PDU 
start the reporting timer with value defined by the Distance reporting timer information element. If the value is "No 
reporting / stop reporting" the MS shall not start or continue reporting. 

While the MS is starting transmission for any reason it shall stop the reporting timer and upon ceasing the transmission 
MS shall start the reporting timer, refer to clause 16.4. 

Upon expiry of the reporting timer the MS shall send a Null PDU unless there is something else already waiting for 
sending. 

After each location update the MS shall check, whether the reporting is to be continued based on the distance reporting 
validity. 

NOTE 1: The protocol model supports various implementation possibilities: 

■ the MM sends null PDUs to the lower layers at reporting intervals and the MAC layer may send the 
null PDUs without taking into account any other transmissions or the MAC may discard sending of 
the Null PDU when it has some else to be sent at the time the Null PDU is due to sending. In those 
options a usage of the MLE-CONFIGURE request primitive is not needed; 

■ the MM informs the MAC layer by the MLE-CONFIGURE request primitive the periodic reporting 
timer value and the MAC layer manages the sending of the Null PDUs. In that case the MM need 
not send Null PDUs. 

If the MS does not support this procedure is should response to the D-DISTANCE REPORTING REQUEST PDU by a 
U-MM PDU/FUNCTION NOT SUPPORTED PDU as defined in clause 16.8.8. 

NOTE 2: There is no MM protocol confirmation that the MS has accepted the distance reporting request. 

16.5 Enable and disable procedures 

MS enable and disable utilizes MM procedures, refer to EN 300 392-7 [8] clause 5. 
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16.6 De-registration procedure 
16.6.1 Trunking mode de-registration 



The de-registration procedure need not be applied. Examples of where the user application may request de-registration 
can be at power down, or if the user specific information, including the ITSI, is removed from the TE. 



USER MM 

TNMM-DEREGISTRATION rei 



TNMM-REPORT ind 



MS 



MLE-UNITDATA req 



BS 



(U-ITSI DETACH) 



MLE-REPORT ind 



MLE air interface MLE 



TL-DATA req 



MM 



TL-DATA con 



Figure 16.7: De registration of lUIS (detachi) 



Upon receipt of a TNMM-DEREGISTRATION request primitive from the user apphcation the MS MM shall send 
a U-ITSI DETACH PDU to the MLE with an MLE-UNITDATA request primitive. This shall have PDU priority 3. 
MM may include the MNI of the MS in the address extension information element the U-ITSI DETACH PDU. 



NOTE: 



The address extension information element cannot act as complete safe guard because there is no 
information element for the IS SI in the PDU 



Upon receipt of the MLE-REPORT indication primitive indicating that the U-ITSI DETACH PDU has been 
successfully or unsuccessfully transmitted by the DLL, MM shall inform the user application of this by issuing a 
TNMM-REPORT indication primitive. 

A MS in the temporarily disabled state shall remain in this state after de-registration. The temporarily disabled state is 
defined in EN 300 392-7 [8]. 

1 6.6.2 Direct mode related de-registration 

MS station may optionally inform SwMI that it leaves trunking mode and goes to direct mode operation without dual 
watch operation and in effect will be no more reachable in the trunking mode. 

Upon reception TNMM-STATUS request primitive with value "Start of direct mode operation" MS shall inform SwMI 
that it is leaving to direct mode operation by sending a U-MM STATUS PDU with status "Start of direct mode 
operation" in a MLE-UNITDATA request PDU. The information element DMO carrier may indicate the DMO RF 
channel to which MS is moving for direct mode operation and the information elements start of direct mode operation 
cause and mode change information may provide further information. The PDU shall use PDU priority 3. MM should 
wait for a MLE-REPORT indication primitive before leaving trunking mode. 

Return to trunking mode operation shall use appropriate registration such as user application initiated periodic 
registration or MLE initiated registration in case the MS has camped on a new cell outside the current RA. 
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16.7 Energy economy 

1 6.7.1 Energy economy mode procedure 
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Figure 16.8: Change energy economy mode 

MS shall initiate this procedure upon receipt of a TNMM-ENERGY SAVING request primitive and the MS MM shall 
issue an MLE-UNITDATA request primitive with a U-MM STATUS PDU carrying U-CHANGE OF ENERGY 
SAVING MODE REQUEST sub-PDU to the infrastructure to request a specific energy economy mode. This PDU shall 
have PDU priority 1 . Timer T352 shall be started. The MS shall inform MAC that no energy economy mode is 
applicable by sending an MLE-INFO request primitive with value "stay alive". 

The energy economy mode may also be requested at registration using U-LOCATION UPDATE DEMAND PDU as 
defined in clauses 16.4.1.1, 16.4.1.2, 16.4.2 and 16.4.3. The BS may respond to this by either normal registration PDU 
or after registration by a D-MM STATUS PDU carrying a D-CHANGE OF ENERGY SAVING MODE RESPONSE 
sub-PDU. 

Upon receipt of a D-MM STATUS PDU carrying a D-CHANGE OF ENERGY SAVING MODE RESPONSE 
sub-PDU or a D-LOCATION UPDATE ACCEPT PDU containing an energy saving information element, timer T352 
shall be stopped and MM shall: 

• if the received information element energy saving mode has another value than "stay alive" MM shall inform 
the lower layers of the energy economy parameters in an MLE-INFO request primitive. The energy economy 
parameters are in the energy economy mode configuration parameter, which shall contain the energy saving 
mode and energy economy start point, the latter shall define the absolute frame and multiframe number of the 
start point. MM shall inform the user application the start of the energy saving mode and its value with a 
TNMM-ENERGY SAVING confirm primitive; 

NOTE 1: The BS may allocate a different energy saving mode than requested and the BS assumes that the allocated 
value will be used. 

• if the received information element energy saving mode has value "stay alive" MM shall inform the user 
application with a TNMM-ENERGY SAVING confirm primitive by setting the energy economy mode status 
parameter value to "rejected" (except in the case of a request to stay alive) and the energy economy mode 
parameter value to "stay alive". 

NOTE 2: If the BS rejected the energy saving mode the MS may try to invoke energy saving mode upon next 
registration. 

BS may change (i.e. modify or stop) or allocate an energy saving mode of an MS at any time by sending 
a D-MM STATUS PDU carrying a D-CHANGE OF ENERGY SAVING MODE REQUEST sub-PDU. 
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Upon reception of the D-MM STATUS PDU carrying the D-CHANGE OF ENERGY SAVING MODE REQUEST 
sub-PDU the MS shall respond to the allocation by sending a U-CHANGE OF ENERGY SAVING MODE 
RESPONSE PDU. In the response the MS shall use the same energy saving mode value as in the D-CHANGE OF 
ENERGY SAVING MODE REQUEST sub-PDU or reject the allocation by using energy saving mode value "stay 
alive". The MM shall inform the user application the start or a change of the energy saving mode and its value with a 
TNMM-ENERGY SAVING indication primitive Energy economy mode may be applicable to a MS in the temporarily 
disabled state. 

MM shall assume that the energy economy mode is lost when RA is changed, and the MS will then need to re-request 
an energy economy mode if it wishes to apply energy saving. 

1 6.7.2 Procedures for requesting Direct Mode dual watcin operation 
16.7.2.1 Introduction 

Dual watch may be performed by an MS that is capable of both Vh-D and TETRA Direct Mode operation 
(see EN 300 396-3 [22]). A full dual watch MS is capable of periodically receiving the Vh-D common control channel 
while in a Direct Mode call, a Direct Mode RF carrier while in a Vh-D call and, when idle, it periodically receives both 
the Direct Mode RF carrier and the V+D common control channel. In order for the MS to periodically receive the V+D 
common control channel while in a Direct Mode call, the MS needs to negotiate with the SwMI to use a periodic 
reception procedure similar to energy economy mode with an appropriate energy economy group. 

An MS supporting idle dual watch is capable of periodically receiving both the Direct Mode RF carrier and the V+D 
common control channel when idle. The MS may not be capable of receiving the V+D common control channel while 
in a Direct Mode call or a Direct Mode RF carrier while in a V+D call. An MS may be forced to operate in idle dual 
watch mode in the case that the MS cannot negotiate a satisfactory energy economy mode with the SwMI or it may be 
totally dependent on the capabilities of the MS. When requesting idle dual watch mode, the MS may negotiate with the 
SwMI to use a periodic reception procedure similar to energy economy mode. When the MS requests direct mode dual 
watch operation, it indicates whether it is requesting full dual watch or idle dual watch by using the "dual watch mode" 
information element of the U-DUAL WATCH MODE REQUEST sub-PDU. 

NOTE: SwMI designers should note that also a full dual watching MS will not always be able to receive in the 
V+D slots corresponding to the agreed energy economy group and, even if the MS receives a V+D 
message, it may not always be able to send a layer 3 response e.g. if it is currently in a Direct Mode call. 
Also, the MS sometimes may not be able to send even a layer 2 response e.g. if it is currently in an 
emergency Direct Mode call. Therefore, if a dual watching MS does not respond to any V+D messages, 
the SwMI should not assume that the MS has left the V+D network unless the MS fails to transmit or 
respond to V+D messages over a long period of time. This time may be longer for an MS that is using 
idle dual watch mode. 

The MS shall inform the SwMI when it wishes to start or resume full dual watch operation with an appropriate energy 
economy group, when it wishes to change the energy economy group associated with its full dual watch operation and 
when it wishes to stop full dual watch operation. The MS may inform the SwMI when it wishes to start or resume idle 
dual watch operation and shall inform the SwMI when it wishes to change the energy economy group associated with 
its dual watch operation; also, if the MS informed the SwMI when it started or resumed idle dual watch operation then it 
shall inform the SwMI when it wishes to stop idle dual watch operation. The procedures defined in the remainder of this 
clause, and in clauses 16.7.2.2 to 16.7.2.6, relate to the full dual watching procedure; they relate also to the idle dual 
watching procedure in the case when the MS informs the SwMI that it is performing idle dual watch. Clause 16.7.2.7 
describes the idle dual watching procedure in the case when the MS does not inform the SwMI that it is performing idle 
dual watch. 

When the MS wishes to start or resume full or idle dual watch operation with an appropriate energy economy group, or 
when it wishes to start or resume idle dual watch operation without using an energy economy group, or when it wishes 
to change the energy economy group associated with its dual watch operation, it uses a U-MM STATUS PDU carrying 
a U-DUAL WATCH MODE REQUEST sub-PDU (see clause 16.7.2.2). When the MS wishes to stop dual watch 
operation, it uses a U-MM STATUS PDU carrying a U-TERMINATING DUAL WATCH MODE REQUEST 
sub-PDU (see clause 16.7.2.3). 

When the MS is in dual watch mode, the SwMI may at any time change the energy economy group associated with the 
MS's dual watch operation or withdraw its acceptance of the MS's dual watch request by sending a D-MM STATUS 
PDU carrying a D-CHANGE OF DUAL WATCH MODE REQUEST sub-PDU (see clause 16.7.2.4). 
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16.7.2.2 MS requesting to start, modify or resume dual watch mode 

Upon receipt of a TNMM-STATUS request primitive with the "dual watch" parameter value set to "starting dual watch 
mode" or "modify or resume dual watch mode", the MS MM shall issue an MLE-UNITDATA request primitive with a 
U-MM STATUS PDU carrying a U-DUAL WATCH MODE REQUEST sub-PDU. If the MS is requesting full dual 
watch mode, the MM shall set the "energy saving mode" information element to request an appropriate energy economy 
group. If the MS is requesting idle dual watch mode, it may include a request for an energy economy group in the PDU; 
alternatively it may set the "energy saving mode" information element to "stay alive". MM shall set the "dual watch 
mode" information element according to the MS capabilities. 

The U-DUAL WATCH MODE REQUEST sub-PDU shall have PDU priority 3. When MM sends the PDU, timer T352 
shall be started and MM shall instruct the MAC to "stay alive" by issuing an MLE-INFO request primitive. 

On receiving a D-MM STATUS PDU carrying a D-DUAL WATCH MODE RESPONSE sub-PDU, timer T352 shall 
be stopped and MM shall perform the following procedure a), b), c) or d) as appropriate: 

a) If the MS requested for full dual watch and the "result of dual watch request" information element indicates 
"Request accepted ..." and the received information element "energy saving mode" has a value appropriate for 
full dual watch, MM shall inform the lower layers of the dual watch parameters in an MLE-INFO request 
primitive. The dual watch parameters are in the "dual watch mode configuration" parameter, which shall 
contain the energy saving mode and the starting frame and multiframe. The energy saving mode shall define 
the dual watch energy economy group and the frame number and multiframe number shall define the dual 
watch start point. The D-DUAL WATCH MODE RESPONSE sub-PDU may contain the "SCCH information 
and distribution on 18th frame" information element, in which case MM shall include the information 
concerning SCCHs and minimum mode configuration in the MLE-INFO request primitive. MM shall inform 
the user application of the acceptance of the dual watch and the value of the energy saving mode with a 
TNMM-STATUS confirm primitive. 

NOTE 1: The SwMI may allocate a different energy saving mode than requested and the SwMI assumes that the 
allocated value will be used. However, the SwMI should not allocate a value of energy saving mode that 
is not appropriate for full dual watch operation (as defined in EN 300 396-3 [22], EN 300 396-4 [23] and 
EN 300 396-7 [25]). 

NOTE 2: For a dual watch activation: 

■ the SwMI should assign a starting point to a full dual watching MS such that the MS's reception 
cycle includes Vh-D frame 18; 

■ the SwMI may need to include the "SCCH information and distribution on 18th frame" information 
element in the D-MM STATUS PDU because it should assign the same common control channel to 
all full dual watching MSs on the same direct mode RF carrier on a cell. 

This allows MSs to maintain Vh-D synchronization and enables compatible cycles for all full dual watching 
MSs on a Direct Mode RF carrier. 

b) If the MS requested for full dual watch and the "result of dual watch request" information element indicates 
"Request accepted ..." but the received information element "energy saving mode" has a value not appropriate 
for full dual watch, MM may either convert to idle dual watch procedures or abandon the dual watch mode 
completely. 

If the MS converts to idle dual watch mode, MM shall inform the lower layers of the dual watch parameters in 
an MLE-INFO request primitive. The dual watch parameters are in the "dual watch mode configuration" 
parameter, which shall contain the energy saving mode and the starting frame and multiframe. The energy 
saving mode shall define the dual watch energy economy group and the frame number and multiframe number 
shall define the dual watch start point. The D-DUAL WATCH MODE RESPONSE sub-PDU may contain the 
"SCCH information and distribution on 18th frame" information element, in which case MM shall include the 
information concerning SCCHs and minimum mode configuration in the MLE-INFO request primitive. MM 
shall inform the user application of the offered idle dual watch and the value of the energy saving mode with a 
TNMM-STATUS confirm primitive. 
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NOTE 3: If the SwMI cannot support an energy saving mode appropriate for full dual watch mode, the SwMI 
should not reject the dual watch request but offer a different energy saving mode or no energy saving 
mode ("stay alive") to the MS. This allows the MS to perform idle dual watch procedures. If the SwMI 
allocates a value of energy saving mode that is not appropriate for full dual watch operation, the SwMI 
should assume that the MS is only capable of the idle dual watch procedure. 

If the user application abandons the offered idle dual watch mode it may either stay in V+D mode or go totally 
to direct mode. If the MS wishes to stay in V+D mode, the MM shall send a U-MM STATUS PDU carrying a 
U-TERMINATING DUAL WATCH MODE REQUEST sub-PDU (see clause 16.7.2.3). If MS wants to go to 
the direct mode, the MM may send a U-MM STATUS PDU carrying a U-START OF DIRECT MODE 
OPERATION sub-PDU (see clause 16.6.2). 

c) If the MS requested for idle dual watch and the "result of dual watch request" information element indicates 
"Request accepted ...", MM shall inform the lower layers of the dual watch parameters in an MLE-INFO 
request primitive. The dual watch parameters are in the "dual watch mode configuration" parameter, which 
shall contain the energy saving mode and the starting frame and multiframe. The energy saving mode shall 
define the dual watch energy economy group and the frame number and multiframe number shall define the 
dual watch start point. The D-DUAL WATCH MODE RESPONSE sub-PDU may contain the "SCCH 
information and distribution on 18th frame" information element, in which case MM shall include the 
information concerning SCCHs and minimum mode configuration in the MLE-INFO request primitive. MM 
shall inform the user application of the acceptance of the idle dual watch and the value of the energy saving 
mode with a TNMM-STATUS confirm primitive. 

NOTE 4: The SwMI may allocate a different energy saving mode than requested and the SwMI assumes that the 
allocated value will be used. 

NOTE 5: If the SwMI cannot support the requested energy saving mode, the SwMI should not reject the dual watch 
request but offer a different energy saving mode or no energy saving mode ("stay alive") to the MS. An 
MS is able to perform idle dual watch procedures with a different energy saving mode or with no energy 
saving mode. 

d) If the "result of dual watch request" information element indicates "Request rejected for undefined reason" or 
"Dual watch not supported", MM shall inform the user application of the rejection of the dual watch request 
with a TNMM-STATUS confirm primitive with the "dual watch" parameter value set appropriately and the 
"energy economy mode" parameter value set according to received "energy saving information" information 
element. 

If the SwMI rejects the dual watch request then the user application may choose to leave V+D operation and 
go to Direct Mode operation, or remain in V+D operation, or use the idle dual watching procedure described in 
clause 16.7.2.7. If the MS leaves V+D operation and goes to Direct Mode operation then the MM may send a 
U-MM STATUS PDU carrying a U-START OF DIRECT MODE OPERATION sub-PDU (see clause 16.6.2). 
If the MS remains in V+D operation then the user application may choose to request normal energy economy 
mode, as defined in clause 16.7.1. The MS may try to request dual watch again after its next registration. 

1 6.7.2.3 MS terminating dual watch mode 

Upon receipt of a TNMM-STATUS request primitive with the "dual watch" parameter value set to "terminating dual 
watch mode", the MS MM shall issue an MLE-UNITDATA request primitive with a U-MM STATUS PDU carrying a 
U-TERMINATING DUAL WATCH MODE REQUEST sub-PDU containing the "energy saving mode" information 
element set to "stay alive". This PDU shall have PDU priority 3. Timer T352 shall be started. MM shall instruct the 
MAC to "stay alive" by issuing an MLE-INFO request primitive. 

On receiving a D-MM STATUS PDU carrying a D-TERMINATING DUAL WATCH MODE RESPONSE sub-PDU, 
timer T352 shall be stopped and MM shall inform the user application with a TNMM-STATUS confirm primitive with 
the "dual watch" parameter value set to "terminating dual watch mode response" and the "energy economy mode" 
parameter value set to "stay alive". 

NOTE: The procedure if the MS wishes to start normal energy economy mode when it terminates dual watch 
mode is described in clause 16.7.2.5 b). 
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16.7.2.4 SwMI modifying or terminating dual watch mode 

If an MS in dual watch mode receives a D-MM STATUS PDU carrying a D-CHANGE OF DUAL WATCH MODE 
REQUEST sub-PDU, the MS MM shall respond to the PDU by sending a U-MM STATUS PDU carrying a 
U-CHANGE OF DUAL WATCH MODE RESPONSE sub-PDU. In the response the MS shall use the same "energy 
saving mode" value as in the D-CHANGE OF DUAL WATCH MODE REQUEST sub-PDU. 

If the "reason for dual watch change by SwMI" information element contains value "change of dual watch energy 
economy group" then the MS shall perform procedure a) or b) as appropriate: 

a) If the MS performs full dual watch and the received "energy saving information" information element contains 
a value appropriate for full dual watch, or the MS performs idle dual watch, MM shall inform the lower layers 
of the modified dual watch parameters in an MLE-INFO request primitive. MM shall inform the user 
application of the modified value of the energy saving mode with a TNMM-STATUS indication primitive. 

b) If the MS performs full dual watch and the received "energy saving information" information element contains 
a value not appropriate for full dual watch, MM may either convert to idle dual watch procedures or abandon 
the dual watch mode completely. 

If the MS converts to idle dual watch mode, MM shall inform the lower layers of the modified dual watch 
parameters in an MLE-INFO request primitive. MM shall inform the user application of the change to idle 
dual watch and the modified value of the energy saving mode with a TNMM-STATUS primitive. 

If the user application abandons the offered idle dual watch mode it may either stay in Vh-D mode or go totally 
to direct mode. If the MS wishes to stay in Vh-D mode, the MM shall send a U-MM STATUS PDU carrying a 
U-TERMINATING DUAL WATCH MODE REQUEST sub-PDU (see clause 16.7.2.3). If MS wants to go to 
the direct mode, the MM may send a U-MM STATUS PDU carrying a U-START OF DIRECT MODE 
OPERATION sub-PDU (see clause 16.6.2). 

NOTE 1: If the SwMI allocates a value of energy saving mode that is not appropriate for full dual watch operation, 
the SwMI should assume that the MS is only capable of the idle dual watch procedure. 

NOTE 2: In the case that the user application abandons the offered idle dual watch mode, the MM is not allowed to 
respond to the D-CHANGE OF DUAL WATCH MODE REQUEST PDU by sending a 
U-TERMINATING DUAL WATCH MODE REQUEST sub-PDU or U-START OF DIRECT MODE 
OPERATION sub-PDU without first sending U-CHANGE OF DUAL WATCH MODE RESPONSE 
sub-PDU. 

If the "reason for dual watch change by SwMI" information element contains value "dual watch terminated for 
undefined reason" then MM shall inform the user application of the termination of dual watch mode by issuing a 
TNMM-STATUS indication primitive and shall instruct the MAC to "stay alive" by issuing an MLE-INFO request 
primitive. The user application may choose to leave Vh-D operation and go to Direct Mode operation, or remain in V+D 
operation, or use the idle dual watching procedure described in clause 16.7.2.7. If the MS leaves V+D operation and 
goes to Direct Mode operation then the MM may send a U-MM STATUS PDU carrying a U-START OF DIRECT 
MODE OPERATION sub-PDU (see clause 16.6.2). If the MS remains in V+D operation then the user application may 
choose to request normal energy economy mode, as defined in clause 16.7.1. The MS may try to request dual watch 
again after its next registration. 

If an MS not in dual watch mode receives a D-MM STATUS PDU carrying a D-CHANGE OF DUAL WATCH MODE 
REQUEST sub-PDU, the MS MM shall respond to the PDU by sending a U-MM STATUS PDU carrying a 
U-CHANGE OF DUAL WATCH MODE RESPONSE sub-PDU with the "energy saving mode" value set to "stay 
alive". This requirement applies only for an MS capable of dual watch operation. 

16.7.2.5 Changing between modes 

An MS cannot operate in both normal energy economy mode and dual watch mode at one time. If the MS wishes to 
change from one mode to the other mode, it shall perform procedure a) or b) as appropriate: 

a) If an MS in energy economy mode receives a TNMM-STATUS request primitive with the "dual watch" 

parameter value set to "starting dual watch mode" then it needs to send only a U-MM STATUS PDU carrying 
a U-DUAL WATCH MODE REQUEST sub-PDU requesting to start dual watch mode (without first sending a 
PDU requesting to end energy economy mode). The procedure shall be as defined in clause 16.7.2.2. 
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b) If an MS in dual watch mode receives a TNMM-ENERGY SAVING request primitive indicating a request to 
start energy economy mode then it shall send a U-MM STATUS PDU carrying a U-TERMINATING DUAL 
WATCH MODE REQUEST sub-PDU containing the "energy saving mode" information element set to the 
value requested for the energy economy mode. This PDU shall have PDU priority 3. Timer T352 shall be 
started. The procedure on receiving a D-MM STATUS PDU carrying a D-TERMINATING DUAL WATCH 
MODE RESPONSE sub-PDU shall then be as defined in clause 16.7.1 for receipt of a D-MM STATUS PDU 
carrying a D-CHANGE OF ENERGY SAVING MODE RESPONSE sub-PDU. 

At the time of sending the PDU requesting the new mode, MM shall instruct the MAC to end the old reception cycle by 
issuing an MLE-INFO request primitive for the old mode indicating "stay alive". Then, if it receives a PDU accepting 
its request, MM shall inform the MAC of the new parameters by issuing an MLE-INFO request primitive for the new 
mode. 

1 6.7.2.6 General dual watch procedures 

Dual watch mode may be applicable to an MS in the temporarily disabled state. 

NOTE 1 : An enable or disable applied to a subscription or an equipment in Vh-D will also apply in Direct Mode 

and vice versa (see EN 300 392-7 [8] and EN 300 396-6 [i.6]). 

Thus, if a dual watching MS receives a disable message on either Vh-D or Direct Mode then that disable 
message applies to both Vh-D and Direct Mode. In the case of a temporary disablement, the MS should 
then continue to receive both the V+D control channel and the Direct Mode RF carrier, looking for an 
enable message i.e. an appropriate V+D MM message or Direct Mode SDS message (if supported); 
during this time, the MS may continue to use the dual watch periodic reception procedure on the V+D 
control channel. If the MS receives an enable message on either V+D or Direct Mode then that enable 
message applies to both V+D and Direct Mode. 

MM shall assume that the dual watch mode is lost when the RA is changed or if the MS needs to re-register for any 
reason other than for a periodic registration. Having successfully re-registered, the MS then needs to send again the 
U-MM STATUS PDU carrying a U-DUAL WATCH MODE REQUEST sub-PDU if it wishes to resume dual watch 
operation. 

NOTE 2: Unlike normal energy economy mode (see clause 16.7.1), the MS cannot use the U-LOCATION 
UPDATE DEMAND PDU to request dual watch operation. 

Both in full and idle dual watch mode the MS may not be able to receive the V+D common control channel while in a 
Direct Mode call, see clause 23.7.7. It is assumed that in both modes, when the MS is participating in a V+D call or 
packet data transfer, it shall receive all the required V+D slots. 

An idle dual watching MS shall obey the normal criteria for registration as if it had been receiving the V+D common 
control channel throughout Direct Mode calls in which it participates. So, at the end of a Direct Mode call, the MS is 
not required to re-register unless the RA has changed or the LA timer has expired (or the MS has received a 
D-LOCATION UPDATE COMMAND PDU from the SwMI). This applies also to a full dual watching MS. 

16.7.2.7 Idle dual watch without informing SwMI 

The procedures defined in clauses 16.7.2.2 to 16.7.2.6 relate to the full dual watching procedure. They relate also to the 
idle dual watching procedure, but only in the case when the MS informs the SwMI that it is performing idle dual watch. 

Alternatively, upon receipt of a TNMM-STATUS request primitive with the "dual watch" parameter value set to 
"starting dual watch mode", the MS may perform the idle dual watching procedure without informing the SwMI that it 
is performing idle dual watch. As in normal idle dual watch, an MS using this form of idle dual watch: 

• is capable of periodically receiving both the Direct Mode RF carrier and the V+D common control channel 
when idle; and 

• may not be capable of receiving the V+D common control channel while it is in a Direct Mode call or a Direct 
Mode RF carrier while it is in a V+D call. 

It is assumed that, when the MS is participating in a V+D call or packet data transfer, it shall receive all the required 
V+D slots. 
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When performing this form of idle dual watch, the MS shall obey the normal V+D procedures except that it is not 
required to receive the V+D common control channel while it is in a Direct Mode call. 

An MS using this form of idle dual watch shall obey the normal criteria for registration as if it had been receiving the 
V+D common control channel throughout Direct Mode calls in which it participates. So, at the end of a Direct Mode 
call, the MS is not required to re-register unless the RA has changed or the LA timer has expired (or the MS has 
received a D-LOCATION UPDATE COMMAND PDU from the SwMI). 

An MS using this form of idle dual watch may choose to request normal energy economy mode, as defined in 
clause 16.7.1. 

This form of idle dual watch mode may be applicable to an MS in the temporarily disabled state. The description in 
clause 16.7.2.6, note 1 applies also to this form of idle dual watch. 

16.7.3 Expiry of timer T352 

On the expiry of timer T352, if it is still possible to solely cancel the outstanding PDU according to clause 16.3.1.3, 
MM shall issue an MLE-CANCEL request primitive with the handle of the transmission request it corresponds to. If it 
is no longer possible to solely cancel the outstanding PDU according to clause 16.3. 1.3, MM shall return 
a TNMM-ENERGY SAVING or TNMM-STATUS confirm primitive with energy saving mode value "stay alive" and a 
failure report to the SAP and the user application should assume that the requested service has failed. 

1 6.8 Attacliment/detacli merit of group identities and group 
reporting procedures 

The attachment/detachment of group identities procedures are illustrated in figures 16.9 and 16.10. Group reporting 
procedures are illustrated in figures 16.1 1 and 16.12. Attachment/detachment of group identities and group reporting 
can be initiated by the user application or it can be requested by the infrastructure. 

The attached group identities, used as valid layer 2 group addresses, shall be defined as follows: 

1) attached by the SwMI, by using D- ATTACH/DETACH GROUP IDENTITY PDU and accepted by the MS 
using the corresponding U- ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU; 

2) previously attached group identities if the attachment/detachment mode in the D-ATTACH/DETACH GROUP 
IDENTITY PDU were an "amendment"; 

3) previously attached group identities which were not detached by the SwMI in the D-ATTACH/DETACH 
GROUP IDENTITY PDU; 

4) attachment requested by the MS by using U-ATTACH/DETACH GROUP IDENTITY or U-LOCATION 
UPDATE DEMAND PDU, and accepted by the SwMI in the corresponding D-ATTACH/DETACH GROUP 
IDENTITY ACKNOWLEDGEMENT or D-LOCATION UPDATE ACCEPT PDU; 

5) previously attached group identities if the attachment/detachment mode in the U-ATTACH/DETACH GROUP 
IDENTITY PDU or U-LOCATION UPDATE DEMAND PDU were an "amendment"; 

6) previously attached group identities which were not detached by the MS by using U-ATTACH/DETACH 
GROUP IDENTITY or U-LOCATION UPDATE DEMAND PDU; 

7) defined with the attachment mode "attachment is not needed". This may be defined either by using group 
identity attachment lifetime information element in the attachment/detachment PDUs or by using other means 
outside of the scope of the present document; 

8) defined to be temporary group address, active during a call (see CMCE protocol in clause 14); 

9) defined and attached by SS-DGNA, refer to EN 300 392-12-22 [17] and not detached by any of the previous 
actions; 

10) previously attached group identities whose group identity attachment lifetime is still valid. 
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The MS shall always use a (V)GSSI as lower layer receiving address instead of the GSSI when the (V)GSSI is assigned 
for the MS in the currently registered SwMI. GSSI shall not be used as an active group identity if the currently 
registered network MCC and MNC is not the same as the MCC and MNC related to the GSSI. 

In case the MS has been temporarily disabled and then enabled by the SwMI, the MS may assume that the groups that 
were attached at the time when the temporary disabling was done are still attached if not otherwise defined by the 
attachment lifetime. However, after enabling the MS shall re-attach the groups having lifetime "Attachment for next 
location update required" if the MS wishes the groups to remain attached. MS may also re-attach any groups. 

Examples of group attachment/detachment message flows are in annex G. 

1 6.8.1 Infrastructure initiated attaclnment/detaclnment of group identities 
procedure 



USER 



MM 



TNMM-ATTACH/DETACH 
GROUP IDENTITY ind 



MS 



MLE-UNITDATA ind 



(D-ATTACH/DETACH 
GROUP IDENTITY) 

MLE-UNITDATA req ^ 



BS 



MLE air interface 



TL-DATA req 



MLE 



MM 



(U-ATTACH/DETACH 
GROUP IDENTITY 
ACKNOWLEDGEMENT) 



MLE-IDENTITIES req 



TL-DATA res 



Figure 16.9: SwMI initiated attachment/detachment of group identities 

When SwMI initiates group attachment/detachment by sending a D-ATTACH/DETACH GROUP IDENTITY PDU it 
shall set the group identity report to "not report request" and the group report response information element shall not be 
included into the PDU. If SwMI wishes to add to or remove some of the group identities attached in the MS it shall set 
the group identity attach/detach mode information element to "amendment". If SwMI wishes to detach all attached 
group identities from the MS and replace the attached group identities by new ones it shall set the group identity 
attach/detach mode information element to "detach all currently attached group identities and attach group identities 
defined in the group identity". 

Upon receipt the D-ATTACH/DETACH GROUP IDENTITY PDU, MM shall inspect the attachment/detachment 
requests for group identities from the PDU. MM shall send valid group identities and related (V)GSSIs with 
an MLE-IDENTITIES request primitive to the MLE. If the group identity acknowledgement request field is set to 
acknowledgement requested, then the MM shall send a U-ATTACH/DETACH GROUP IDENTITY 
ACKNOWLEDGEMENT PDU to the MLE in an MLE-UNITDATA request primitive. The U-ATTACH/DETACH 
GROUP IDENTITY_ACKNOWLEDGEMENT PDU shall contain rejected attachments and may contain accepted 
attachments and detachments, refer to annex F. Those group identities which were in the D-ATTACH/DETACH 
GROUP IDENTITY PDU but are not contained in the U-ATTACH/DETACH GROUP IDENTITY 
ACKNOWLEDGEMENT PDU are accepted. PDU priority shall be set to 6. Finally the MM shall inform the user 
application about changes in attached/detached group identities by issuing a TNMM-ATTACH/DETACH GROUP 
IDENTITY indication primitive. The MM shall inform the user application using only the GTSIs while the (V)GSSIs is 
not known by the user application. 

Infrastructure initiated attachment/detachment of group identities is not applicable to a MS in the temporarily disabled 
state and MS shall not send U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU or modify 
group information. 
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1 6.8.2 MS initiated attaclnment/detaclnment of group identities procedure 



USER 



MM 



TNMM-ATTACH/DETACH 
GROUP IDENTITY req__ 



TNMM-ATTACH/DETACH 
GROUP IDENTITY con 



MS 



MLE-UNITDATA req 



BS 



MLE air interface MLE 



TL-DATA res 



MM 



(U-ATTACH/DETACH 
GROUP IDENTITY) 
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ACNOWLEDGEMENT) 

MLE-IDENTITIES req ^, 



TL-DATA req 



Figure 16.10: MS initiated attachment/detachment of group identities, acltnowledgement requested 

Upon receipt of a TNMM-ATTACH/DETACH GROUP IDENTITY request primitive from the user application the 
MM shall send a U-ATTACH/DETACH GROUP IDENTITY PDU to the MLE in an MLE-UNITDATA request 
primitive using parameters defined in the TNMM-ATTACH/DETACH GROUP IDENTITY request primitive (see 
clause 17). MM shall set the group identity report to "not report request" and the group report response information 
element shall not be included into the PDU. If MS wishes to add to or remove some of the group identities attached in 
the MS it shall set the group identity attach/detach mode information element to "amendment". If MS wishes to detach 
all attached group identities form the MS and replace the attached group identities by new ones it shall set the group 
identity attach/detach mode information element to "detach all currently attached group identities and attach group 
identities defined in the group identity". PDU priority shall be set to 3. Timer T353 shall be started. 

The MM should not try to attach those group identities which have been permanently detached by the current network. 
In addition the MM should not try to attach those group identities which have earlier been attached in the current 
network with parameter values "Attachment not allowed for next ITSI attach" if the group is not already attached. 

NOTE: Independently of the attachment lifetime the MS is allowed to re-attach a group which is currently 

attached, when the user application within MS for example changes the class of usage value of the group. 

Upon receipt of a D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU, timer T353 shall be 
stopped. The D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU shall indicate those group 
identities which were not accepted with a rejection reason in the group identity detachment downlink information 
element, refer to clause 16.10.20, and it may contain also accepted group identities. The SwMI may reject group 
identity detachment by adding the group attachment into the D-ATTACH/DETACH GROUP IDENTITY 
ACKNOWLEDGEMENT PDU. 

If the MS requested attachment/detachment of group identities, the MM shall examine whether the attachments and/or 
detachments requested were accepted by the SwMI. The MM shall send the attached group identities and related 
(V)GSSIs with MLE-IDENTITIES request primitive to the MLE. 

If the group identity downlink information element does not explicitly contain the group attachment lifetime 
information element, then the applied lifetime is outside the scope of the present document. 

Finally the MM shall inform the user application by issuing a TNMM-ATTACH/DETACH GROUP IDENTITY 
confirm primitive. The MM shall inform the user application using only the GTSIs since the (V)GSSIs is not known by 
the user application. 

MS initiated attachment/detachment of group identities is not applicable to a MS in the temporarily disabled state. In the 
temporary disabled state upon receipt of a TNMM-ATTACH/DETACH GROUP IDENTITY request primitive MM 
shall not send a U-ATTACH/DETACH GROUP IDENTITY PDU and may issue a TNMM-DISABLING indication 
primitive to the user application. 
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1 6.8.3 SwMI initiated group report procedure 



USER 



MM 



TNMM-ATTACH/DETACH 
GROUP IDENTITY ind 



MS 



BS 

MLE air interface MLE MM 



TL-DATA ind 



MLE-UNITDATA ind 



(D-ATTACH/DETACH 
GROUP IDENTITY) 

MLE-UNITDATA req 



(U-ATTAGH/DETACH 
GROUP IDENTITY) 

MLE-UNITDATA ind 



(D-ATTACH/DETACH 
GROUP IDENTITY 
ACKNOWLEDGE) 

MLE-IDENTITIES req 



TL-DATA req 



TL-DATA con 



Figure 16.11: SwMI initiated group report 

In the SwMI initiated group report procedure, the SwMI requests the MS to start group attachment and the MS shall 
re-attach those groups it wishes to remain valid, including group identities with lifetime parameter value "Attachment 
not needed". When receiving the group report request, the MM shall regard all the group identities no more attached. If 
the MS wishes to receive signalling on those group identities, the MM has to re-attach them. The MM should not try to 
attach those group identities which have been permanently detached by the current network. In addition the MM should 
not try to attach those group identities which have earlier been attached in the current network with parameter values 
"Attachment not allowed for next ITSI attach" if the group is not already attached. The attachment request may also 
contain group identities which were temporarily detached or indicated as unknown by the SwMI, refer to 
clause 16.10.20. 

Upon receipt of the D-ATTACH/DETACH GROUP IDENTITY PDU from the MLE, MM shall check that the group 
identity report information element indicates that a "group report" is requested. The group identity acknowledgement 
request information element value shall be "acknowledgement not requested", MS shall ignore the value of the group 
identity attach/detach mode information element and group identity downlink information elements shall not be present 
in the PDU. As the response MM shall send a U- ATTACH/DETACH GROUP IDENTITY PDU containing the 
reported groups, the group identity attach/detach mode information element shall be set to "detach all currently attached 
group identities and attach group identities defined in the group identity" and the group identity report information 
element to "not report request" and if all the reported groups do fit into one U- ATTACH/DETACH GROUP 
IDENTITY PDU it shall contain a group report response information element indicating "group report complete". The 
PDU priority shall be set to 3. Timer T353 shall be started. If the reported groups do not fit in one 
U- ATTACH/DETACH GROUP IDENTITY PDU, the group report response information element shall not be included 
and subsequent groups shall be reported using U -ATTACH/DETACH GROUP IDENTITY PDUs as presented above 
except that the group identity attach/detach mode information element shall be set to "Amendment". The PDU priority 
shall be set to 3. Timer T353 shall be started. MM shall expect that each U-ATTACH/DETACH GROUP IDENTITY 
PDU is acknowledged individually before sending next U-ATTACH/DETACH GROUP IDENTITY PDU by the 
corresponding D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU. 

Upon receipt of each D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU, timer T353 shall be 
stopped. MM shall send the accepted and thus attached group identities and related (V)GSSIs with the MLE-IDENTIES 
request primitive to the MLE. 

In the last U-ATTACH/DETACH GROUP IDENTITY PDU containing the last reported group, the Group report 
response information element shall be present and set to "Group report complete". 
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If the MS has no groups to report, the Group report response information element shall be present and set to "Group 
report complete", the Group identity uplink information element shall not be present and the Group identity 
attach/detach mode shall be set to "detach all currently attached group identities and attach group identities defined in 
the group identity". 

Infrastructure initiated group reporting is not applicable to a MS in the temporarily disabled state and MS shall not send 
U- ATTACH/DETACH GROUP IDENTITY PDU or modify group information. 

16.8.4 MS initiated group report procedure 
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Figure 16.12: MS initiated group report 

In the MS initiated group report procedure MS requests SwMI to start group attachment and the SwMI shall re-attach 
those groups it wishes to be attached in the MS and thus be valid downlink identities. 

Upon receipt of a TNMM-ATTACH/DETACH GROUP IDENTITY request primitive containing group report request 
from the user appUcation the MM shall send a U-ATTACH/DETACH GROUP IDENTITY PDU containing the value 
"report request" in the group identity report information element. The group identity attach/detach mode information 
element value shall be "amendment", and group identity uplink information elements shall not be present in the PDU. 
The PDU priority shall be set to 3. Timer T353 shall be started. 

If the SwMI accepts the group report request it shall send a D-ATTACH/DETACH GROUP IDENTITY PDU 
containing the group identity attach/detach mode information element set to "detach all currently attached group 
identities and attach group identities defined in the group identity.." and the group identity acknowledgement request 
information element set either to "acknowledgement requested" or "acknowledgement not requested" and if all reported 
groups fit into one D-ATTACH/DETACH GROUP IDENTITY PDU, the "Group report response" information element 
shall be included and indicate "group report complete". 

If the Group identity downlink information element is not present and the Group report response information element 
indicates "group report complete", then the SwMI has no groups to report. 

If the reported groups do not fit in one D-ATTACH/DETACH GROUP IDENTITY PDU, the Group report response 
information element shall not be included and subsequent groups shall be reported using D-ATTACH/DETACH 
GROUP IDENTITY PDUs as presented above except that the group identity attach/detach mode information element 
shall be set to "Amendment". 

In the last D-ATTACH/DETACH GROUP IDENTITY PDU the Group report response information element shall be 
included and indicate "group report complete". 
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Upon receipt of each D-ATTACH/DETACH GROUP IDENTITY PDU, T353 shall be stopped, if running. The MS 
shall check that the Group identity attach/detach mode element is "detach all currently attached group identities and 
attach group identities defined in the group identity..". The MM shall send the attached group identities and related 
(V)GSSIs with MLE-IDENTITIES request to the MLE. When the Group report response element indicates that the 
group report is complete MS knows that is has received the whole group information. If the group identity 
acknowledgement request information element was set to "acknowledgement requested", MM shall individually 
acknowledge each D-ATTACH/DETACH GROUP IDENTITY PDU by sending the corresponding 
U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU. PDU priority shall be set to 6. 

If the MS initiated group reporting collides with a SwMI initiated group attachment the MS can detect it when the 
attach/detach mode is "amendment" and the MS shall assume that the actual report will follow later and shall not send 
the corresponding U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU as long as the timer 
T353 is running. 

MS initiated group reporting is not applicable to a MS in the temporarily disabled state. In the temporary disabled state 
upon receipt of a TNMM- ATTACH/DETACH GROUP IDENTITY request primitive MM shall not send a 
U-ATTACH/DETACH GROUP IDENTITY PDU and may issue a TNMM-DISABLING indication primitive to the 
user application. 



16.8.5 Expiry of timer T353 



On the expiry of timer T353, if it is still possible to solely cancel the outstanding PDU according to clause 16.3.1.3, 
MM shall issue an MLE-CANCEL request primitive with the handle of the transmission request it corresponds to. If it 
is no longer possible to solely cancel the outstanding PDU according to clause 16.3.1.3, MM shall return a failure report 
to the SAP and the user application should assume that the requested service has failed. 

1 6.8.6 Colliding requests for group attachment/detachment and group 
reporting 

In the event that one party (MS / SwMI) sends attachment / detachment requests by its own initiative at the same time 
as the other party is requesting group report, the report request shall override the other requests. Therefore MS/SwMI 
must respond to the report request and abandon its own attachment / detachment request. 

In case MS is attempting registration or SwMI is initiating registration at the same time as the other party is sending 
group report request or attachment / detachment requests, the registration shall override the other requests. 

1 6.8.7 Group Identity Address Type (GIAT) usage in group identity 
downlink/uplink 

The Group Identity Address Type (GIAT) shall be used in the Group identity downlink and Group identity uplink 
information elements to signify the group address information present for each group. 

The group address information present in the Group identity uplink information element shall be as follows: 

• if MS attaches/acknowledges groups belonging to its home network, i.e. MNI of the group is the same as MNI 
of the home network of MS: 

if the MS is registered to its home system, the GSSI information element shall be present (GIAT shall be 
set to 0); 

if the MS is registered to a foreign system and the SwMI has not previously allocated a (V)GSSI to the 
group, the GSSI and address extension information elements shall be present (GIAT shall be set to 1); 

if the MS is registered to a foreign system and the SwMI has previously allocated (V)GSSI, the (V)GSSI 
information element shall be present (GIAT shall be set to 2). 

• if the MS is registered to a foreign network and attaches/acknowledges groups belonging to the current 
network, i.e. MNI of the group is the same as MNI of the foreign network MS is registered to: 

the GSSI information element shall be present (GIAT shall be set to 0); or 

the GSSI and address extension information elements shall be present (GIAT shall be set to 1). 



ETSI 



348 ETSI TS 100 392-2 V3.3.1 (2008-10) 

The group address information present in the Group identity downlink information element shall be as follows: 

• if SwMI attaches/acknowledges groups belonging to the home network of MS, i.e. MNI of the group is the 
same as MNI of the home network of MS: 

if the MS is registered to its home system, the GSSI information element shall be present (GIAT shall be 

set to 0); 

if the MS is registered to a foreign network, the GSSI and address extension information elements were 
present in the Group Identity uplink and the SwMI rejected the attachment then the GSSI and address 
extension information elements shall be present (GIAT shall be set to 1); 

if the MS is registered to a foreign network and the (V)GSSI was present in the Group Identity uplink, 
the (V)GSSI information element (which shall be the same (V)GSSI as present in the Group Identity 
uplink) shall be present (GIAT shall be set to 2); 

if the MS is registered to a foreign network and the SwMI is initiating a group attachment/detachment 
and a (V)GSSI has not yet been allocated to the group, the GSSI, address extension and (V)GSSI 
information elements shall be present (GIAT shall be set to 3); 

if the MS is registered to a foreign network and the SwMI is initiating a group attachment/detachment, 
and a (V)GSSI has already been allocated to the group, then either the (V)GSSI information element 
shall be present (GIAT shall be set to 2) or the GSSI, address extension and (V)GSSI information 
elements shall be present (GIAT shall be set to 3); 

if the MS is registered to a foreign network, the GSSI and address extension information elements were 
present in the Group Identity Uplink and the SwMI accepted the attachment then the GSSI, address 
extension and (V)GSSI information elements shall be present (GIAT shall be set to 3); 

if the MS is registered to a foreign network and the SwMI requires to allocate a new (V)GSSI to a GTSI 
which has previously been allocated a (V)GSSI (i.e. the new (V)GSSI replaces the existing (V)GSSI) 
then the GSSI, address extension and (V)GSSI information elements shall be present (GIAT shall be set 
to 3); 

if the MS is registered to a foreign network and the MS has initiated a group report for a GTSI and the 
SwMI has previously allocated a (V)GSSI for the GTSI, then the GSSI, address extension and (V)GSSI 
information elements shall be present (GIAT shall be set to 3). 

• if the MS is registered to a foreign network and SwMI attaches/acknowledges groups belonging to the current 
network, i.e. MNI of the group is the same as MNI of the current network MS is registered to: 

the GSSI information element shall be present (GIAT shall be set to 0); or 

the GSSI and address extension information elements shall be present (GIAT shall be set to 1). 



1 6.8.8 PDU or function not supported 



In case MS/SwMI receives an individually addressed unknown MM PDU or a request for a MM function which is not 
supported, the receiving entity may send MM PDU/FUNCTION NOT SUPPORTED PDU. The behaviour of the 
requesting party when receiving MM PDU/FUNCTION NOT SUPPORTED PDU is outside the scope of the present 
document. 

NOTE: The same PDU may be used for several functions, e.g. by sending U-LOCATION UPDATE DEMAND 
PDU the MS may request either group attachment/detachment or group report and D-LOCATION 
UPDATE COMMAND PDU may also include a group report request in addition to the registration 
request. 
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16.9 MM PDU Structures and contents 

16.9.1 MM PDU general description 

Refer to annex E for PDU encoding rules and examples. The usage of security related information elements is presented 
in EN 300 392-7 [8] and the usage of DMO gateway related information elements is presented in EN 300 396-5 [24]. 

The information contained in the PDU description tables which follow corresponds to the following key: 

• Length: length of the information element in bits; 

• Type: information element type (1, 2 or 3) as defined below; 

• C/O/M: conditional/optional/mandatory information in the PDU; 

• Remark: comment. 

1 6.9.2 MM PDU description tables - downlink 



16.9.2.1 



D-ATTACH/DETACH GROUP IDENTITY 



Message: 
Response to: 
Response expected: 
Short description: 



D-ATTACH/DETACH GROUP IDENTITY 

-U- ATTACH/DETACH GROUP IDENTITY (report request) 

-/U- ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 

The infrastructure sends this message to the MS to indicate 
attachment/detachment of group identities for the MS or to initiate a group 
report request or give a group report response. 



Table 16.1: D-ATTACH/DETACH GROUP IDENTITY PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-ATTACH/DETACH GROUP IDENTITY 


Group identity report 


1 


1 


M 




Group identity acl<nowledgement request 


1 


1 


M 




Group identity attach/detach mode 


1 


1 


M 




Proprietary 




3 







Group report response 




3 







Group identity downlinl< 




4 







Group Identity Security Related Information 




4 





See EN 300 392-7 [8] 
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16.9.2.2 



D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 



Message: 
Response to: 
Response expected: 
Short description: 



D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 
U- ATTACH/DETACH GROUP IDENTITY 



The infrastructure sends this message to the MS to acknowledge MS initiated 
attachment/detachment of group identities. 



Table 16.2: D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-ATTACH/DETACH GROUP 
IDENTITY ACKNOWLEDGEMENT 


Group identity accept/reject 


1 


1 


M 




Reserved 


1 


1 


M 




Proprietary 




3 







Group identity downlink 




4 







Group Identity Security Related Information 




4 





See EN 300 392-7 [8] 



16.9.2.3 



16.9.2.4 



16.9.2.5 



Void 



Void 



D-MM STATUS 



1 6.9.2.5.1 D-MM STATUS generic structure 

• Message: D-MM STATUS 



• Response to: 

• Response expected: 

• Short description: 



-/U-MM STATUS 

-/U-MM STATUS 

The infrastructure sends this message to the MS to request or indicate/reject 
a change of an operation mode. 

Table 16.3: D-MM STATUS PDU generic contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


See notes 1 and 3 


Status downlink dependant information 


variable 






See note 2 


NOTE 1 : This information element shall indicate the requested service or a response to a request and the 

sub-type of the D-MM STATUS PDU. 
NOTE 2: This information element or set of information elements shall be as defined by the status downlink 

information element, refer to clauses 16.9.2.5.1 to 16.9.2.5.7. 
NOTE 3: This Status downlink element is indicating which sub-PDU this D-MM STATUS PDU contains. In case 

the receiving party does not support indicated function but is able to recognize this PDU structure, it 

should set the received value of Status downlink element to Not-supported sub PDU type element. 
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16.9.2.5.2 



D-CHANGE OF ENERGY SAVING MODE REOUEST 



The status downlink information element value "Change of energy saving mode request" defines the D-CHANGE OF 
ENERGY SAVING MODE REQUEST PDU and the D-MM STATUS PDU shall contain information elements as 
defined in table 16.4. 



Message: 
Response to: 
Response expected: 
Short description: 



D-CHANGE OF ENERGY SAVING MODE REQUEST 



U-CHANGE OF ENERGY SAVING MODE RESPONSE 

The infrastructure sends this message to the MS to modify or stop a current 
energy economy mode, or allocate an energy economy mode. 



Table 16.4: D-CHANGE OF ENERGY SAVING MODE REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


D-CHANGE OF ENERGY SAVING 
MODE REQUEST 


Energy saving information 


14 


1 


M 




Proprietary 


variable 


3 








16.9.2.5.3 



D-CHANGE OF ENERGY SAVING MODE RESPONSE 



The status downlink information element value "Change of energy saving mode response" defines the D-CHANGE OF 
ENERGY SAVING MODE RESPONSE PDU and the D-MM STATUS PDU shall contain information elements as 
defined in table 16.5. 



Message: 
Response to: 
Response expected: 
Short description: 



D-CHANGE OF ENERGY SAVING MODE RESPONSE 
U-CHANGE OF ENERGY SAVING MODE REQUEST 



The infrastructure sends this message to the MS to indicate the start point of an 
accepted energy economy mode or to reject a request for energy economy mode. 



Table 16.5: D-CHANGE OF ENERGY SAVING MODE RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


D-CHANGE OF ENERGY 
SAVING MODE RESPONSE 


Energy saving information 


14 


1 


M 




Proprietary 


variable 


3 
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16.9.2.5.4 



D-DUAL WATCH MODE RESPONSE 



The status downlink information element value "Dual watch mode response" defines the D-DUAL WATCH MODE 
RESPONSE PDU and the D-MM STATUS PDU shall contain information elements as defined in table 16.6. 



Message: 
Response to: 
Response expected: 
Short description: 



D-DUAL WATCH MODE RESPONSE 
U-DUAL WATCH MODE REQUEST 



The infrastructure sends this message to the MS to indicate the start point of an 
accepted dual watch energy economy mode or to reject a request for dual watch 
mode. 



Table 16.6: D-DUAL WATCH MODE RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


D-DUAL WATCH MODE 
RESPONSE 


Energy saving information 


14 


1 


M 




Result of dual watch request 


3 


1 


M 




Reserved 


8 


1 


M 


Default value = OOOOOOOOg 


SCCH information and distribution on 18* frame 


6 


2 







Proprietary 




3 








16.9.2.5.5 



D-TERMINATING DUAL WATCH MODE RESPONSE 



The status downlink information element value "Terminating dual watch mode response" defines the 
D-TERMINATING DUAL WATCH MODE RESPONSE PDU and the D-MM STATUS PDU shall contain 
information elements as defined in table 16.7. 



Message: 
Response to: 
Response expected: 
Short description: 



D-TERMINATING DUAL WATCH MODE RESPONSE 
U-TERMINATING DUAL WATCH MODE REQUEST 



The infrastructure sends this message to the MS to accept a request to terminate 
dual watch and may optionally indicate the start point of an accepted energy 
economy mode after dual watch operation. 



Table 16.7: D-TERMINATING DUAL WATCH MODE RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


D-TERMINATING DUAL 
WATCH MODE RESPONSE 


Reserved 


8 


1 


M 


Default value = OOOOOOOOg 


Energy saving information 


14 


2 







SCCH information and distribution on 18* frame 


6 


2 







Proprietary 




3 
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16.9.2.5.6 



D-CHANGE OF DUAL WATCH MODE REOUEST 



The status downlink information element value "Change of dual watch mode request" defines the D-CHANGE OF 
DUAL WATCH MODE REQUEST PDU and the D-MM STATUS PDU shall contain information elements as defined 
in table 16.8. 



Message: 
Response to: 
Response expected: 
Short description: 



D-CHANGE OF DUAL WATCH MODE REQUEST 



U-CHANGE OF DUAL WATCH MODE RESPONSE 

The infrastructure sends this message to the MS to change the energy economy 
group associated with the MS's dual watch operation or to withdraw its previous 
acceptance of the MS's dual watch request. 



Table 16.8: D-CHANGE OF DUAL WATCH MODE REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


D-CHANGE OF DUAL WATCH 
MODE REQUEST 


Energy saving information 


14 


1 


M 




Reason for dual watch change by SwMI 


3 


1 


M 




Reserved 


8 


1 


M 


Default value = OOOOOOOOg 


SCCH information and distribution on 18* frame 


6 


2 







Proprietary 




3 








16.9.2.5.7 



Direct mode gateway related D-MM STATUS 



The status downlink information element the values in the range OIOOOO2 to 01 1 1 1 12 indicate a DMO gateway function 
and the D-MM STATUS PDU shall contain information elements as defined in EN 300 396-5 [24] annex B. 



16.9.2.5.8 



D-MS FREOUENCY BANDS REOUEST 



The status downlink information element value "MS frequency bands request" defines the D-FREQUENCY BANDS 
REQUEST PDU and the D-MM STATUS PDU shall contain information elements as defined in table 16.9. 



Message: 
Response to: 
Response expected: 
Short description: 



D-MS FREQUENCY BANDS REQUEST 



U-MS FREQUENCY BANDS INFORMATION 

The infrastructure sends this message to the MS to interrogate the frequency 
bands that are supported by the MS. 



Table 16.9: D-MS FREQUENCY BANDS REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


D-MS FREQUENCY BANDS REQUEST 


Proprietary 


variable 


3 
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16.9.2.5.9 



DISTANCE REPORTING REQUEST 



The status downlink information element value "Distance reporting request" defines the D-DISTANCE REPORTING 
REQUEST PDU and the D-MM STATUS PDU shall contain information elements as defined in table 16.10. 



Message: 
Response to: 
Response expected: 
Short description: 



D-DISTANCE REPORTING REQUEST 



The infrastructure sends this message request that the MS shall send a Null 
PDU, if the timer has elapsed. The Null PDU will be used to measure the path 
delay for that MS. 



Table 16.10: D-DISTANCE REPORTING REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-MM STATUS 


Status downlink 


6 


1 


M 


D-DISTANCE REPORTING REQUEST 


Distance reporting timer 


7 


1 


M 




Distance reporting validity 


1 


1 


M 




Proprietary 




3 








16.9.2.6 



Void 



16.9.2.7 



D-LOCATION UPDATE ACCEPT 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



D-LOCATION UPDATE ACCEPT 



U-LOCATION UPDATE DEMAND 



The infrastructure sends this message to the MS to indicate that updating in the 
network has been completed. 



Table 16.11 : D-LOCATION UPDATE ACCEPT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-LOCATION UPDATE 
ACCEPT 


Location update accept type 


3 


1 


M 




SSI 


24 


2 





ASSI/(V)ASSI of MS 


Address extension 


24 


2 





MNI of MS 


Subscriber class 


16 


2 







Energy saving information 


14 


2 







SCCH information and distribution on 18"^ frame 


6 


2 







New registered area 




4 







Group identity location accept 




3 







Default group attachment lifetime 




3 







Authentication downlink 




3 





See EN 300 392-7 [8] 


Group Identity Security Related Information 




4 





See EN 300 392-7 [8] 


Proprietary 




3 
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16.9.2.8 



D-LOCATION UPDATE COMMAND 



Message: 
Response to: 
Response expected: 
Short description: 



D-LOCATION UPDATE COMMAND 



U-LOCATION UPDATE DEMAND 



The infrastructure sends this message to the MS to initiate a location update 
demand in the MS. 



Table 16.12: D-LOCATION UPDATE COMMAND contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-LOCATION UPDATE COMMAND 


Group identity report 


1 


1 


M 




Cipher control 


1 


1 


M 




Ciphering parameters 


10 




C 


See note 


Address extension 


24 


2 





MNIoftheMS 


Proprietary 




3 







NOTE: Information element "Ciphering parameters" is not present if "Cipher control" is set to "0", "ciphering off". 
Information element "ciphering parameters" is present if "Cipher control" is set to "1", "ciphering on". 



16.9.2.9 



D-LOCATION UPDATE REJECT 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



D-LOCATION UPDATE REJECT 



U-LOCATION UPDATE DEMAND 



The infrastructure sends this message to the MS to indicate that updating in the 
network is not accepted. 

Table 16.13: D-LOCATION UPDATE REJECT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-LOCATION UPDATE REJECT 


Location update type 


3 


1 


M 




Reject cause 


5 


1 


M 




Cipher control 


1 


1 


M 




Ciphering parameters 


10 




C 


See note 


Address extension 


24 


2 





MNIoftheMS 


Proprietary 




3 







NOTE: Information element "Ciphering parameters" is not present if "Cipher control" is set to "0", "ciphering off". 
Information element "Ciphering parameters" is present if "Cipher control" is set to "1", "ciphering on". 
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Message: 
Response to: 
Response expected: 
Short description: 



D-LOCATION UPDATE PROCEEDING 
U-LOCATION UPDATE DEMAND 



The infrastructure sends this message to the MS on registration at accepted 
migration to assign a (V) ASSI. 



Table 16.14: D-LOCATION UPDATE PROCEEDING contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-LOCATION UPDATE PROCEEDING 


SSI 


24 


1 


M 


(V)ASSI of the MS 


Address extension 


24 


1 


M 


MNIoftheMS 


Proprietary 




3 








1 6.9.3 MM PDU descriptions - uplink 



16.9.3.1 



U-ATTACH/DETACH GROUP IDENTITY 



Message: 
Response to: 
Response expected: 
Short description: 



U-ATTACH/DETACH GROUP IDENTITY 

-/D-ATTACH/DETACH GROUP IDENTITY (report request) 

D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 

The MS sends this message to the infrastructure to indicate 
attachment/detachment of group identities in the MS or to initiate a group report 
request or give a group report response. 



Table 16.15: U-ATTACH/DETACH GROUP IDENTITY contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-ATTACH/DETACH GROUP IDENTITY 


Group identity report 


1 


1 


M 




Group identity attach/detach mode 


1 


1 


M 




Group report response 




3 







Group identity uplink 




4 







Proprietary 




3 
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16.9.3.2 



U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 



Message: 
Response to: 
Response expected: 
Short description: 



U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 
D- ATTACH/DETACH GROUP IDENTITY 



The MS sends this message to the infrastructure to acknowledge SwMI initiated 
attachment/detachment of group identities. 



Table 16.16: U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-ATTACH/DETACH GROUP IDENTITY 
ACKNOWLEDGEMENT 


Group identity acl<nowledgement type 


1 


1 


M 




Group identity uplink 




4 







Proprietary 




3 








16.9.3.3 



U-ITSI DETACH 



Message: 
Response to: 
Response expected: 
Short description: 



U-ITSI DETACH 



-/D-MM STATUS 



The MS sends this message to the infrastructure to announce that the MS will be 
de-activated. 

Table 16.17: U-ITSI DETACH contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-ITSI DETACH 


Address extension 


24 


2 





MNIoftheMS 


Proprietary 




3 
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16.9.3.4 U-LOCATION UPDATE DEMAND 

• Message: U-LOCATION UPDATE DEMAND 

• Response to: -/D-LOCATION UPDATE COMMAND 

• Response expected: D-LOCATION UPDATE ACCEPT/D-LOCATION UPDATE REJECT 

• Short description: The MS sends this message to the infrastructure to request update of its location 

registration. 

Table 16.18: U-LOCATION UPDATE DEMAND contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-LOCATION UPDATE DEMAND 


Location update type 


3 


1 


M 




Request to append LA 


1 


1 


M 




Ciplier control 


1 


1 


M 




Cipliering parameters 


10 




C 


See note 


Class of MS 


24 


2 







Energy saving mode 


3 


2 







LA information 




2 







SSI 


24 


2 





ISSI of the MS 


Address extension 


24 


2 





MNIoftheMS 


Group identity location demand 




3 







Group report response 




3 







Authentication uplink 




3 





See EN 300 392-7 [8] 


Extended capabilities 




3 







Proprietary 




3 







NOTE: Information element "Ciphering parameters" is not present if "Cipher control" is set to "0", "ciphering off". 
Information element "ciphering parameters" is present if "Cipher control" is set to "1", "ciphering on". 



16.9.3.5 



U-MM STATUS 



1 6.9.3.5.1 U-MM STATUS generic construction 

• Message: U-MM STATUS 

• Response to: -/D-MM STATUS 

• Response expected: -/D-MM STATUS 

• Short description: 



The MS sends this message to the infrastructure to request or respond to a mode 
change. 

Table 16.19: U-MM STATUS PDU generic contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-MM STATUS 


Status uplink 


6 


1 


M 


See notes 1 and 3 


Status uplink dependent information 


variable 






See note 2 


NOTE 1 : This information element shall indicate the requested service or a response to a request and the 

sub-type of the U-MM STATUS PDU. 
NOTE 2: This information element or set of information elements shall be as defined by the status uplink 

information element, refer to clauses 16.9.3.5.1 to 16.9.3.5.8. 
NOTE 3: This Status uplink element is indicating which sub-PDU this U-MM STATUS PDU contains. In case the 

receiving party does not support indicated function but is able to recognize this PDU structure, it should 

set the received value of Status uplink element to Not-supported sub PDU type element. 
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16.9.3.5.2 



U-CHANGE OF ENERGY SAVING MODE REOUEST 



The status uplink information element value "Change of energy saving mode request" indicates the U-CHANGE OF 
ENERGY SAVING MODE REQUEST PDU and the U-MM STATUS PDU shall contain information elements as 
defined in table 16.20. 



Message: 
Response to: 
Response expected: 
Short description: 



U-CHANGE OF ENERGY SAVING MODE REQUEST 



D-CHANGE OF ENERGY SAVING MODE RESPONSE 

The MS sends this message to the infrastructure to change its energy economy 
mode i.e. to start or end energy economy operation or to change the energy 
economy group. 



Table 16.20: U-CHANGE OF ENERGY SAVING MODE REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-MM STATUS 


Status uplink 


6 


1 


M 


U-CHANGE OF ENERGY SAVING MODE REQUEST 


Energy saving mode 


3 


1 


M 




Proprietary 


variable 


3 








16.9.3.5.3 



U-CHANGE OF ENERGY SAVING MODE RESPONSE 



The status uplink information element value "Change of energy saving mode response" indicates the U-CHANGE OF 
ENERGY SAVING MODE RESPONSE PDU and the U-MM STATUS PDU shall contain information elements as 
defined in table 16.21. 



Message: 
Response to: 
Response expected: 
Short description: 



U-CHANGE OF ENERGY SAVING MODE RESPONSE 
D-CHANGE OF ENERGY SAVING MODE REQUEST 



The MS sends this message to the infrastructure to accept or reject a change of its 
energy economy mode. 



Table 16.21: U-CHANGE OF ENERGY SAVING MODE RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-MM STATUS 


Status uplink 


6 


1 


M 


U-CHANGE OF ENERGY SAVING MODE RESPONSE 


Energy saving mode 


3 


1 


M 




Proprietary 


variable 


3 
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16.9.3.5.4 



U-DUAL WATCH MODE REQUEST 



The status uplink information element value "Dual watch mode request" indicates the U-DUAL WATCH MODE 
REQUEST PDU and the U-MM STATUS PDU shall contain information elements as defined in table 16.22. 



Message: 
Response to: 
Response expected: 
Short description: 



U-DUAL WATCH MODE REQUEST 



D-DUAL WATCH MODE RESPONSE 



The MS sends this message to the infrastructure to request start of dual watch 
operation with an appropriate energy economy group or to change the energy 
economy group associated with its dual watch operation or to re-request dual 
watch operation after a re-registration. 



Table 16.22: U-DUAL WATCH MODE REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 




M 


U-MM STATUS 


Status uplink 


6 




M 


U-DUAL WATCH MODE REQUEST 


Energy saving mode 


3 




M 




MS operating witti type 2 repeater 


1 




M 




Dual watcii mode 


1 




M 




DMO carrier 


13/25 


2 







Start of Direct Mode Operation cause 


3 


2 







Mode cinange information 


6 


2 







Proprietary 




3 








16.9.3.5.5 



U-TERMINATING DUAL WATCH MODE REOUEST 



The status uplink information element value "Terminating dual watch mode request" indicates the U-TERMINATING 
DUAL WATCH MODE REQUEST PDU and the U-MM STATUS PDU shall contain information elements as defined 
in table 16.23. 



Message: 
Response to: 
Response expected: 
Short description: 



U-TERMINATING DUAL WATCH MODE REQUEST 



D-TERMINATING DUAL WATCH MODE RESPONSE 

The MS sends this message to the infrastructure to indicate an end of dual watch 
mode and, optionally, requesting energy economy operation. 



Table 16.23: U-TERMINATING DUAL WATCH MODE REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-MM STATUS 


Status uplink 


6 


1 


M 


U-TERMINATING DUAL WATCH MODE REQUEST 


Reserved 


8 


1 


M 


Default value = OOOOOOOOg 


Energy saving mode 


3 


2 







Proprietary 




3 
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16.9.3.5.6 



U-CHANGE OF DUAL WATCH MODE RESPONSE 



The status uplink information element value "Change of dual watch mode response" indicates the U-CHANGE OF 
DUAL WATCH MODE RESPONSE PDU and the U-MM STATUS PDU shall contain information elements as 
defined in table 16.23. 



Message: 
Response to: 
Response expected: 
Short description: 



U-CHANGE OF DUAL WATCH MODE RESPONSE 
D-CHANGE OF DUAL WATCH MODE REQUEST 



The MS sends this message to the infrastructure to accept a change to its dual 
watch operation (or to reject the change if it is not currently operating in dual 
watch). 



Table 16.24: U-CHANGE OF DUAL WATCH MODE RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-MM STATUS 


Status uplink 


6 


1 


M 


U-CHANGE OF DUAL WATCH MODE RESPONSE 


Energy saving mode 


3 


1 


M 




Reserved 


8 


1 


M 


Default value = OOOOOOOO2 


Proprietary 




3 








16.9.3.5.7 



U-START OF DIRECT MODE OPERATION 



The status uplink information element value "Start of direct mode operation" indicates the U-START OF DIRECT 
MODE OPERATION PDU and the U-MM STATUS PDU shall contain information elements as defined in table 16.25. 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



U-START OF DIRECT MODE OPERATION 



The MS sends this message to the infrastructure to indicate a start of direct mode 
operation without dual watch. 



Table 16.25: U-START OF DIRECT MODE OPERATION PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-MM STATUS 


Status uplink 


6 


1 


M 


U-START OF DIRECT MODE OPERATION 


Reserved 


5 


1 


M 


Default value = OOOOOg 


DMO carrier 


13/25 


2 







Start of direct mode operation cause 


3 


2 







Mode change information 


6 


2 







Proprietary 




3 
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16.9.3.5.8 



Direct mode gateway related U-MM STATUS 



For the status uplink information element the values in the range OIOOOO2 to01111l2 indicate a DMO gateway function 
and the U-MM STATUS PDU shall contain information elements as defined in EN 300 396-5 [24], annex B. 



16.9.3.5.9 



U-MS FREQUENCY BANDS INFORMATION 



The status uplink information element value "MS frequency bands information" defines the U-MS FREQUENCY 
BANDS INFORMATION PDU and the U-MM STATUS PDU shall contain information elements as defined in 
table 16.26. 



• Message: 

• Response to: 



Response expected: 
Short description: 



U-MS FREQUENCY BANDS INFORMATION 
-/D-MS FREQUENCY BANDS REQUEST 



The MS sends this message to the infrastructure to indicate which frequency 
bands it supports. 



Table 16.26: U-MS FREQUENCY BANDS PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


U-MM STATUS 


Status uplink 


6 


1 


M 


MS FREQUENCY BANDS REQUEST 


Number of frequency band definitions 


3 


1 


M 




Frequency band definition 


37 




C 


See note 


Proprietary 




3 







NOTE: This information element shall be present as many times as defined by the number of frequency band 
definitions information element. If the element has value 0, the Frequency band definition element is 
not present. 
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1 6.9.4 PDU description tables - downlinl< and uplinl< 



16.9.4.1 



MM PDU/FUNCTION NOT SUPPORTED 



Message: 
Response to: 
Response expected: 
Short description: 



MM PDU/FUNCTION NOT SUPPORTED 
Any individually addressed MM PDU 



This PDU may be sent by the MS/LS or SwMI to indicate that the received MM 
PDU or the function indicated in the PDU is not supported. 



Table 16.27: MM PDU/FUNCTION NOT SUPPORTED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU type 


4 


1 


MM 


M 


MM PDU/FUNCTION 
NOT SUPPORTED 


Not-supported PDU type 


4 


1 


MM 


M 


See note 1 


Not-supported sub PDU type 


variable 


2 


MM 





See note 2 


Length of the copied PDU 


8 


2 


MM 







Received PDU contents 


variable 




MM 


C 


See notes 3 and 4 


NOTE 1 : This information element shall identify the received PDU which contains the function which cannot be 
supported. 

NOTE 2: In case the receiving party recognizes the PDU and the PDU contains a sub-PDU field (like in 

U/IVI-MM STATUS PDU, U/D-OTAR, U/D-ENABLE, etc.) this element contains the element indicating 
which sub-PDU this is. 

NOTE 3: The length of this element is indicated by the Length of the copied PDU element. This element is not 
present if the Length of the copied PDU element is not present. 

NOTE 4: This element contains the received PDU beginning from and excluding the PDU type element. 



16.10 MM information elements coding 
16.10.1 Address extension 

The address extension information element shall indicate the extended part of TSI address as defined in table 16.28. 
Table 16.28: Address extension information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Mobile Country Code (MCC) 


10 


1 


M 




Mobile Network Code (MNC) 


14 


1 


M 





16.10.2 Cipher control 

The cipher control information element shall indicate whether ciphering is on or off as defined in table 16.29. 
Table 16.29: Cipher control information element contents 



Information element 


Length 


Value 


Remark 


Cipher Control 


1 





Ciphering off 






1 


Refer to EN 300 392-7 [8] 
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16.10.3 Cipher parameters 

For the cipher parameters information element refer to EN 300 392-7 [8]. 

16.10.4 Void 

16.10.5 Class of MS 

The class of MS information element shall indicate to the infrastructure the characteristics of the MS terminal, both 
hardware and software. The total information element length is 24 bits and the values can be given both as a bit map 
and as values. The decoding shall be as defined in table 16.30. 

Table 16.30: Class of MS information element contents 



Information sub-element 


Length 


Value 


Remark 


Frequency simplex/duplex 







Frequency simplex supported 


1 


Frequency duplex and simplex supported 


Single/multislot 







Single slot supported 


1 


IVIultislot and single slot supported 


Concurrent multicarrier operation 







Single carrier operation supported 


1 


Multi and single carrier operation supported 


Voice 







No voice calls supported 


1 


Voice calls supported 


End-to-end encryption 







End-to-end encryption supported 


1 


End-to-end encryption not supported 


Circuit mode data 







No circuit mode data supported 


1 


Circuit mode data supported 


TETRA packet data 







TETRA packet data not supported 


1 


TETRA packet data supported 


Fast switching on a pliase-modulated 
channel 







Fast switching not supported on a phase-modulated 
channel 


1 


Fast switching supported on a phase-modulated 
channel 


DCK air interface encryption 







DCK air interface encryption not supported 


1 


DCK air interface encryption supported 


CLCH needed on carrier change 







No CLCH needed on carrier change 


1 


CLCH needed on carrier change 


Concurrent circuit mode services 
(see note) 







Concurrent circuit mode services not supported 


1 


Concurrent circuit mode services supported 


Original advanced link 







Original advanced link not supported 


1 


Original advanced link supported 


Minimum mode 







IVIinimum mode not supported 


1 


IVIinimum mode supported 


Carrier specific signalling channel 







Carrier specific signalling channel not supported 


1 


Carrier specific signalling channel supported 


Authentication 







Authentication not supported 


1 


Authentication supported 


SCK air interface encryption 







SCK air interface encryption not supported 


1 


SCK air interface encryption supported 
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Information sub-element 


Length 


Value 


Remark 


TETRA air interface standard 
version number 


3 


OOO2 


ETS 300 392-2 (edition 1), no security functions 


001 2 


ETS 300 392-2 (edition 1) and EN 300 392-7 [8] 
(V2.1.1) 


01 O2 


EN 300 392-2 V2.3.2 to V2.6.1 and EN 300 392-7 [8] 
V2.1.1 toV2.4.1 


0112 


EN 300 392-2 v3.1 .1 to V3.3.1 and EN 300 392-7 [8] 
V3.1.1 


1002 


Reserved 


etc. 


etc. 


III2 


Reserved 


Common SCCH 


1 





Common SCCH not supported 


1 


Common SCCH supported 


Reserved 


1 





Default value 


1 


Reserved for future expansion 


IVIAC-D-BLCK PDU and augmented 
cliannel allocation 


1 





MAC-D-BLCK PDU not supported and augmented 
channel allocations not supported 


1 


IVIAC-D-BLCK PDU supported and augmented 
channel allocations supported 


Extended advanced link{s) 


1 





Extended advanced link(s) not supported 


1 


Extended advanced link(s) supported 


D8PSK 


1 





D8PSK modulation mode not supported 


1 


D8PSK modulation mode supported 


NOTE: If concurrent circuit mode services are supported it is implicit that concurrent channels are supported. 
If concurrent circuit mode services are not supported concurrent channels are implicitly supported if the 
Packet Data MS type is of type "A" see clause 28.3.3.4.1 



16.10.6 Class of usage 

The class of usage information element shall define priority of the group identity as defined in table 16.31. The class of 
usage has meaning only for the user application. 

Table 16.31 : Class of Usage Information element contents 



Information element 


Length 


Value 


Remark 


Class of usage 


3 


OOO2 


Class of usage 1 


OOI2 


Class of usage 2 


01 O2 


Class of usage 3 


OII2 


Class of usage 4 


IOO2 


Class of usage 5 


IOI2 


Class of usage 6 


IIO2 


Class of usage 7 


III2 


Class of usage 8 



16.10.7 Disabling type 

For the disabling type information element refer to EN 300 392-7 [8]. 
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16. 10.7a Default group attachment lifetime 

The default group attachment lifetime information element shall indicate the default lifetime of the attachment of all 
group identities attached by the infrastructure for a MS as defined in table 16.32. 

Table 16.32: Default group attachment lifetime information element contents 



Information element 


Length 


Value 


Remark 


Default group attachment lifetime 


2 


OOg 


Attachment not needed 


OI2 


Attachment for next ITS! attach required 


IO2 


Attachment not allowed for next ITSI attach 


II2 


Attachment for next location update required 



16. 10.7b Distance reporting timer 

The distance reporting timer information element shall indicate the maximum time between MS transmissions as 
defined in table 16.33. 

Table 16.33: Distance reporting timer information element contents 



Information element 


Length 


Value 


Remark 


Distance reporting timer 


7 





No reporting / stop reporting 


1 


15s 


2 


30 s 


etc. 


etc. 


127 


31 min 45 s 



16.1 0.7c Distance reporting validity 



The distance reporting validity information element shall indicate the reporting validity as defined in table 16.34. 
Table 16.34: Distance reporting validity information element contents 



Information element 


Length 


Value 


Remark 


Distance reporting validity 


1 





Report until next location update 


1 


Report until next ITSI attach or migration 



1 6.1 0.8 Distribution on 1 8th frame 

The distribution on 18th frame information element shall indicate on which of the 4 time slots the MS shall monitor 
down link information in the case of minimum mode as defined in table 16.35. 

Table 16.35: Distribution on 18th frame information element contents 



Information element 


Length 


Value 


Remark 


Distribution on 18'*^ frame 


2 


OO2 


Time slot 1 


OI2 


Time slot 2 


IO2 


Time slot 3 


II2 


Time slot 4 
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1 6.1 0.8a DMO carrier 

The DMO carrier information element shall indicate the DMO radio channel as defined in table 16.36. 

Table 16.36: DMO carrier 



Information sub-element 


Lengtii 


Type 


C/O/IM 


Value 


Remark 


Carrier number 


12 


1 


M 




Carrier frequency number (see note 1) 


Extended carrier 
numbering flag 


1 


1 


M 





No extended carrier numbering 


1 


Extended carrier numbering 


Frequency band 


4 




C 




Provision for different frequency 
bands (see notes 1 and 2) 


Offset 


2 




C 




Provision for different offsets, (see 
notes 2 and 3) 


Duplex spacing 


3 




c 




Provision for different duplex spacing 
(see notes 1 , 2 and 4) 


DIVIO normal/reverse 
operation 


1 




c 





DMO uplink frequency = 

DMO downlink frequency 

+ duplex spacing (see notes 2 and 4) 


1 


DMO uplink frequency = 

DMO downlink frequency 

- duplex spacing (see notes 2 and 4) 


Reserved 


2 




c 


002 


Default value = OOg (see note 2) 


NOTE 1 : Refer to annex F for meaning of the values. 

NOTE 2: These information elements shall be present only when the extended carrier numbering flag has value 
"extended carrier numbering". 

NOTE 3: Refer to clause 21 .4.4.1 , table 333 for the meaning of the offset values. 

NOTE 4: When an IVIS requesting dual watch mode or indicating start of Direct Mode operation transmits the 

DMO carrier information element, it shall set the carrier number to indicate the Direct Mode RF carrier 
where it intends to receive. If using extended carrier numbering, the MS shall set the duplex spacing 
information element to indicate 0,0 MHz duplex value unless the MS expects to use a two-frequency 
Direct Mode repeater during its dual watch operation in which case it may set the duplex spacing 
information element with the DMO normal/reverse operation information element to indicate the uplink 
Direct Mode RF carrier. When a Direct Mode gateway transmits the DMO carrier information element 
(see EN 300 396-5 [24]), it shall indicate the Direct Mode RF carrier where it intends to transmit. In the 
case of a two-frequency combined repeater/gateway, the repeater/gateway shall set the duplex 
spacing information element with the DMO normal/reverse operation information element to indicate 
the uplink Direct Mode RF carrier. 



1 6. 1 0.8b Dual watch mode 

The dual watch mode information element shall indicate whether the MS is requesting to use full dual watch or idle 
dual watch as defined in table 16.37. 

Table 16.37: Dual watch mode information element contents 



Information element 


Length 


Value 


Remark 


Dual watch mode 


1 





Full dual watch 


1 


Idle dual watch 
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1 6. 1 0.9 Energy saving mode 

The energy saving mode information element shall indicate which energy saving or dual watch scheme is requested (if 
any) as defined in table 16.38, refer to clause 23.7.6 for the meaning of the values. 

Table 16.38: Energy saving mode information element contents 



Information element 


Length 


Value 


Remark 


Energy saving mode 


3 


OOO2 


Stay Alive 


OOI2 


Economy mode 1 (EGI) 


01 O2 


Economy mode 2 {EG2) 


OII2 


Economy mode 3 {EG3) 


IOO2 


Economy mode 4 {EG4) 


IOI2 


Economy mode 5 {EG5) 


11 O2 


Economy mode 6 {EG6) 


III2 


Economy mode 7 {EG7) 



16.10.10 Energy saving information 

The energy saving information element shall indicate which energy saving or dual watch scheme is allocated (if any) 
and starting point of the energy economy mode as defined in table 16.39. 

Table 16.39: Energy saving information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Energy saving mode 


3 


1 


M 




Frame Number 


5 


1 


M 


See note 1 


IVIultiframe Number 


6 


1 


M 


See note 2 


NOTE 1 : When the Energy saving mode information element value is "Stay alive" this information element has 

no meaning and it shall be set to "OOOOO2". 
NOTE 2: When the Energy saving mode information element value is "Stay alive" this information element has 

no meaning and it shall be set to "OOOOOO2". 



1 6. 1 0. 1 0a Extended capabilities 

The extended capabilities information element shall be a collection of sub-elements as defined in table 16.40. It shall 
indicate to the infrastructure additional capabilities supported by the MS terminal, both hardware and software. 

Table 16.40: Extended capabilities information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Value 


Remark 


Air to ground 


1 


1 


M 





MS does not support air to ground service 


1 


MS supports air to ground service 


Reserved 


17 


1 


M 




Shall be set to all zeros in the present 
document 


QAM capabilities 


16 


2 









Reserved 


16 


2 







Shall not be included in the present document 


Reserved 


16 


2 







Shall not be included in the present document 


Reserved 


16 


2 







Shall not be included in the present document 


Reserved 


16 


2 







Shall not be included in the present document 


Reserved 


16 


2 







Shall not be included in the present document 


Reserved 


16 


2 







Shall not be included in the present document 


Reserved 


16 


2 







Shall not be included in the present document 
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16.10.11 Frame Number 

The Frame Number (FN) information element shall indicate TDM A frame number as defined in table 16.41. 
Table 16.41 : Frame number information element contents 



Information element 


Length 


Value 


Remark 


Frame Number 


5 


OOOOO2 


Reserved 


00001 2 


FN1 


0001 O2 


FN2 


etc. 


etc. 


IOOIO2 


FN18 


IOOII2 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 



16.10.11a Frequency band definition 

The frequency band definition information element shall indicate the frequency capabilities of the MS as defined in 
table 16.42. 

Table 16.42: Frequency band definition information element contents 



Information element 


Length 


Type 


C/O/M 


Value 


Remark 


Lower edge carrier 


12 




M 




See notes 1 and 2 


Lower edge frequency band 


4 




M 




See note 1 


Upper edge carrier 


12 




M 




See notes 1 and 2 


Upper edge frequency band 


4 




M 




See note 1 


Duplex spacing 


3 




M 




See note 1 


Reverse operation types 


2 




M 


OO2 


Reserved 


OI2 


Reverse operation only 


IO2 


Normal operation only 


II2 


Both normal and reverse operation 


N0TE1: Refer to TS 100 392-1 5 [18]. 

NOTE 2: The frequency band sliall be defined as tlie BS transmitter frequency range. 



16. 10. 12 Group identity accept/reject 

The group identity accept/reject information element shall indicate the infrastructure response type to the MS initiated 
attachment/detachment of group identities as defined in table 16.43. 

Table 16.43: Group identity accept/reject information element contents 



Information element 


Length 


Value 


Remark 


Group identity accept/reject 


1 





All attachment/detachments accepted 


1 


At least one attachment/detachment rejected 
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16. 10. 13 Group identity acl^nowledgement request 

The group identity acknowledgement request information element shall indicate the MS response to the infrastructure 
initiated attachment/detachment of group identities as defined in table 16.44. 

Table 16.44: Group identity acltnowledgement request information element contents 



Information element 


Length 


Value 


Remark 


Group identity acl<nowledgement request 


1 





Acl<nowledgement not requested 


1 


Acl<nowledgement requested 



16.10.14 Group identity acl^nowledgement type 

The group identity acknowledgement type information element shall indicate the MS response type to the infrastructure 
initiated attachment/detachment of group identities as defined in table 16.45. 

Table 16.45: Group identity acknowledgement type information element contents 



Information element 


Length 


Value 


Remark 


Group identity acknowledgement type 


1 





All attachment/detachments accepted 


1 


At least one attachment rejected 



16.10.15 Group identity address type 

The group identity address type information element shall indicate type of group identity address type in the 
attachment/detachment of group identities as defined in table 16.46. 

Table 16.46: Group identity address type information element contents 



Information element 


Length 


Value 


Remark 


Group identity address type 


2 


OO2 


GSSI 


OI2 


GTSI 


IO2 


(V)GSSI 


II2 


GTSI+(V)GSSI 



16.10.16 Group identity attacinment lifetime 

The group identity attachment lifetime information element shall indicate a lifetime of the attachment of the group 
identity defined by the infrastructure for a MS as defined in table 16.47. 

Table 16.47: Group identity attachment lifetime information element contents 



Information element 


Length 


Value 


Remark 


Group identity attachment lifetime 


2 


OO2 


Attachment not needed 


OI2 


Attachment for next ITS! attach required 


IO2 


Attachment not allowed for next ITSI attach 


II2 


Attachment for next location update required 
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16. 10. 17 Group identity attacln/detacin mode 

The group identity attach/detach mode information element shall indicate a mode of the attachment/detachment of 
group identities as defined in table 16.48. 

Table 16.48: Group identity attach/detach mode information element contents 



Information element 


Length 


Value 


Remark 


Group identity attach/detach mode 


1 





Amendment 


1 


Detach all currently attached group identities 
and attach group identities defined in the group 
identity (downlink/uplink) element (if any) 



16.1 0.1 8 Group identity attacin/detacin type identifier 

The group identity attach/detach type identifier information element shall indicate the whether a group identity is 
attached or detached as defined in table 16.49. 

Table 16.49: Group identity attach/detach type identifier information element contents 



Information element 


Length 


Value 


Remark 


Group identity attach/detach type identifier 


1 





Attachment 


1 


Detachment 



16. 10. 19 Group identity attaclnment 

The group identity attachment information element shall be a collection of sub elements and defined in table 16.50. 
Table 16.50: Group identity attachment information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity attachment lifetime 


2 


1 


M 




Glass of Usage 


3 


1 


M 





1 6. 1 0.20 Group identity detaclnment downlink 

The group identity detachment downlink information element shall indicate the infrastructure detachment reasons as 
defined in table 16.51. 

Table 16.51 : Group identity detachment downlink information element contents 



Information element 


Length 


Value 


Remark 


Group identity detachment downlink 


2 


OO2 


Unknown group identity 


OI2 


Temporary 1 detachment (see note) 


IO2 


Temporary 2 detachment (see note) 


II2 


Permanent detachment 


NOTE: These values are network dependent. 
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16.10.21 Group identity detachment uplinl< 

The group identity detachment uphnk information element shall indicate the MS detachment reasons as defined in 
table 16.52. 

Table 16.52: Group identity detachment uplinit information element contents 



Information element 


Length 


Value 


Remark 


Group identity detachment uplinl< 


2 


OO2 


Unknown group identity 


OI2 


No valid encryption l<ey (end-to-end) 


IO2 


User initiated 


II2 


Capacity exceeded 



1 6. 1 0.22 Group identity downlink 

The group identity downlink information element shall be a collection of sub elements and defined in table 16.53. 
Table 16.53: Group identity downlink information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity attach/detach type identifier 


1 


1 


M 




Group identity attachment 


5 




C 


See note 1 


Group identity detachment downlink 


2 




C 


See note 1 


Group identity address type 


2 


1 


M 




GSSI 


24 




C 


See note 2 


Address EXTENSION 


24 




C 


See note 2 


(V) GSSI 


24 







See note 2 


NOTE 1 : Shall be conditional on the value of Group Identity Attach/Detach Type Identifier (GIADTI): 

- GIADTI = 0; Group Identity Attachment; 

- GIADTI = 1 ; Group Identity Detachment Downlink. 

NOTE 2: Shall be conditional on the value of Group Identity Address Type (GIAT): 

- GIAT = 0; GSSI; 

- GIAT = 1 ; GSSI + Address Extension (GTSI); 

- GIAT = 2; Visitor Group Short Subscriber Identity ({V)GSSI); 

- GIAT = 3; GSSI + Extension + Visitor Group Short Subscriber Identity (GTSI-V(GSSI)). 



16. 10.23 Group identity location accept 

The group identity location accept information element shall be a collection of sub elements and defined in table 16.54. 
Table 16.54: Group identity location accept information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity accept/reject 


1 


1 


M 


See note 


Reserved 


1 


1 


M 




Group identity downlink 




4 







NOTE: Accept/reject has meaning only when acknowledging IVIS group identity attachment/detachment. 
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16. 10.24 Group identity location demand 

The group identity location demand information element shall be a collection of sub elements and defined in 
table 16.55. 

Table 16.55: Group identity location demand information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Reserved 


1 


1 


M 




Group identity attach/detach mode 


1 


1 


M 




Group identity uplink 




4 








16.10.25Void 

16. 10.26 Group identity report 

The group identity report information element shall indicate that all MS's active group identities must be reported as 
defined in table 16.56. 

Table 16.56: Group identity report information element contents 



Information element 


Length 


Value 


Remark 


Group identity report 


1 





Not report request 


1 


Report request 



16.10.27Group identity uplinl< 

The group identity uplink information element shall be a collection of sub elements and defined in table 16.57. 
Table 16.57: Group identity uplink information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity attacli/detach type identifier 


1 


1 


M 




Glass of usage 


3 







See note 1 


Group identity detachment uplink 


2 







See note 1 


Group identity address type 


2 


1 


M 




GSSI 


24 







See note 2 


Address extension 


24 







See note 2 


(V) GSSI 


24 







See note 2 


NOTE 1 : Shall be conditional on the value of Group Identity Attach/Detach Type Identifier (GIADTI): 

- GIADTI = 0; Glass of Usage; 

- GIADTI = 1 ; Group Identity Detachment uplink. 

NOTE 2: Shall be conditional on the value of Group Identity Address Type (GIAT): 

- GIAT = 0; GSSI; 

- GIAT = 1 ; GSSI + Address Extension (GTSI); 

- GIAT = 2; Visitor Group Short Subscriber Identity ((V)GSSI); 

- GIAT = 3; Reserved. 



16.10.27a Group report response 

The group report response information element shall indicate that the group report is complete as defined in table 16.58. 
Table 16.58: Group report response information element contents 



Information element 


Length 


Value 


Remark 


Group report response 


1 





Group report complete 


1 


Reserved 
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16. 10.28 Group Short Subscriber Identity (GSSI) 

The GSSI information element shall indicate the GSSI or (V)GSSI that the MS shall use in subsequent contacts with the 
SwMI. It is also used during attachment/detachment to explicitly inform the full GTSI when used in conjunction with 
the extension element as defined in table 16.59. 

Table 16.59: GSSI information element contents 



Information element 


Length 


Value 


Remark 


GSSI 


24 




See EN 300 392-1 [6], clause 7 



16.1 0.29 KSG number 

For the KSG number information element refer to EN 300 392-7 [8]. 

16. 10.30 LA 

The LA information element shall indicate the area in which a cell is located, either the serving cell or a neighbour cell 
as defined in table 16.60. 

Table 16.60: LA information element contents 



Information element 


Length 


Value 


Remark 


LA 


14 







16.10.31 LACC 

The LACC information element shall indicate which LACC the MS wants to use as defined in table 16. 6L The element 
shall only be signalled if it is different from the country code used in the network, i.e. the MS is migrating. 

Table 16.61 : Location Area Country Code information element contents 



Information element 


Length 


Value 


Remark 


Location Area Country Code 


10 




See EN 300 392-1 [6], clause 7 (MCC) 



16. 10.32 LANG 

The LANC information element shall indicate which LANC the MS wants to use as defined in table 16.62. The element 
is only signalled if it is different from the network code used in the network, i.e. the MS is roaming. 

Table 16.62: LANC information element contents 



Information element 


Length 


Value 


Remark 


Location Area Network Code 


14 




See EN 300 392-1 [6] clause 7 (MNC) 
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16. 10.33 LA timer 

The LA timer information element shall indicate the time a LA is valid as defined in table 16.63. 

Table 16.63: LA timer information element contents 



Information element 


Length 


Value 


Remark 


LA timer 


3 


OOO2 


10 min 


OOI2 


30 min 


01 O2 


1 hour 


OII2 


2 hours 


IOO2 


4 hours 


IOI2 


8 hours 


11 O2 


24 hours 


III2 


no timing 



16. 10.34 LA information 

The LA information element shall be a collection of information elements as defined in table 16.64. 

Table 16.64: LA information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Location Area (LA) 


14 


1 


M 




Zero bit 


1 


1 


M 





16.10.34a Lengtin of tine copied PDU 

The Length of the copied PDU information element shall indicate the length of the Received PDU contents information 
element as defined in table 16.65. 

Table 16.65: Length of the copied PDU information element contents 



Information sub-element 


Length 


Value 


Remark 


Length of the copied PDU 


8 


OOOOOOOO2 


Obits 


00000001 2 


1 bit 


0000001 O2 


2 bits 


etc. 


etc. 


IIIIIIII2 


255 bits 
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1 6. 1 0.35 Location update type 

The purpose of the location updating type Information element shall indicate what type of registration is wanted as 
defined in table 16.66. 

Table 16.66: Location update type information element contents 



Information element 


Length 


Value 


Remark 


Location update type 


3 


OOO2 


Roaming location updating 


OOI2 


IVIigrating location updating 


01 O2 


Periodic location updating 


OII2 


ITS! attach 


IOO2 


Call restoration roaming location updating 


IOI2 


Call restoration migrating location updating 


11 O2 


Demand location updating 


III2 


Disabled MS updating 



1 6.1 0.35a Location update accept type 

The location update accept type information element shall indicate the type of registration in the D-LOCATION 
UPDATE ACCEPT PDU as defined in table 16.67. 

Table 16.67: Location update accept type information element contents 



Information element 


Length 


Value 


Remark 


Location update type 


3 


OOO2 


Roaming location updating 


OOI2 


Temporary registration 


01 O2 


Periodic location updating 


OII2 


ITS! attach 


IOO2 


Call restoration roaming location updating 


IOI2 


Migrating or call restoration migrating location updating 


IIO2 


Demand location updating 


III2 


Disabled MS updating 



1 6.1 0.36 Mobile Country Code (MCC) 



The MCC information element shall indicate to which MCC the MS is subscribed as defined in table 16.68. 

Table 16.68: MCC information element contents 



Information element 


Length 


Value 


Remark 


MCC 


10 




See EN 300 392-1 [6], clause 7 (MCC) 



16. 10.37 Mobile Network Code (MNC) 

The MNC information element shall indicate to which MNC the MS is subscribed as defined in table 16.69. 

Table 16.69: MNC information element contents 



Information element 


Length 


Value 


Remark 


MNC 


14 




See EN 300 392-1 [6], clause 7 (MNC) 
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16.10.37a Mode change information 

Mode change information element shall indicate additional information related to a direct mode or dual watch 
invocation as defined in table 16.70. 

Table 16.70: Mode change information element contents 



Information element 


Length 


Value 


Remark 


Mode change information 


6 


OOOOOO2 


Reserved 


etc. 


etc. 


IIIIII2 


Reserved 



16.10.37b MS operating witin type 2 repeater 

The MS operating with type 2 repeater information element shall indicate whether the MS expects to use a type 2 Direct 
Mode repeater during its dual watch operation, as defined in table 16.71. This may affect the appropriate energy 
economy groups (see EN 300 396-7 [25]). 

Table 16.71 : MS operating with type 2 repeater information element contents 



Information element 


Length 


Value 


Remark 


IVIS operating with type 2 repeater 


1 





IVIS does not expect to use a type 2 Direct Mode repeater 


1 


MS expects to use a type 2 Direct Mode repeater 



16.1 0.38 Multiframe Number (MN) 

The Multiframe Number (MN) information element shall indicate TDMA multiframe number as defined in table 16.72. 
Table 16.72: Multiframe number information element contents 



Information element 


Length 


Value 


Remark 


Multiframe Number (MN) 


6 


OOOOOOg 


Reserved 


000001 2 


MN1 


00001 O2 


MN2 


etc. 


etc. 


1 1 1 1 0O2 


MN60 


IIIIOI2 


Reserved 


etc. 


etc. 


IIIIII2 


Reserved 



16.10.38a Not-supported PDU type 

See clause 16.10.39 PDU type element. 
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1 6.1 0.38b Number of frequency band definitions 

The Number of the frequency band definitions information element shall indicate the how many frequency band 
definitions the PDU contains as defined in table 16.73. 

Table 16.73: Number of the frequency band definitions information element contents 



Information sub-element 


Length 


Value 


Remark 


Number of the frequency band definitions 


3 


OOO2 









001 2 


1 






01 O2 


2 






etc. 


etc. 






III2 


7 



16. 10.39 PDU type 

The PDU type information element shall identify an up-link and down-link message. The PDU type information 
element shall have a separate definition in the uplink and downlink directions as defined in table 16.74. 

Table 16.74: PDU type information element contents 



Information 
element 


Length 


Value 


Remark 


Downlink 


Uplink 


PDU type 


4 


OOOO2 


D-OTAR, see EN 300 392-7 [8]. 


U-AUTHENTICATION, see 
EN 300 392-7 [8] 


OOOI2 


D-AUTHENTICATION, see 
EN 300 392-7 [8] 


U-ITSI DETACH 


001 O2 


D-CK CHANGE DEMAND, see 
EN 300 392-7 [8] 


U-LOCATION UPDATE DEMAND 


OOII2 


D-DISABLE, see EN 300 392-7 [8] 


U-MM STATUS 


OIOO2 


D-ENABLE, see EN 300 392-7 [8] 


U-CK CHANGE RESULT, see 
EN 300 392-7 [8] 


OIOI2 


D-LOCATION UPDATE ACCEPT 


U-OTAR, see EN 300 392-7 [8] 


OIIO2 


D-LOCATION UPDATE COMMAND 


Reserved 


OIII2 


D-LOCATION UPDATE REJECT 


U-ATTACH/DETACH GROUP 
IDENTITY 


IOOO2 


Reserved 


U-ATTACH/DETACH GROUP 
IDENTITY ACK 


IOOI2 


D-LOCATION UPDATE 
PROCEEDING 


U-TEI PROVIDE, see 
EN 300 392-7 [8] 


IOIO2 


D-ATTACH/DETACH GROUP 
IDENTITY 


Reserved 


IOII2 


D-ATTACH/DETACH GROUP 
IDENTITY ACK 


U-DISABLE STATUS, see 
EN 300 392-7 [8] 


IIOO2 


D-MM STATUS 


Reserved 


IIOI2 


Reserved 


Reserved 


IIIO2 


Reserved 


Reserved 


IIII2 


MM PDU/FUNCTION NOT 
SUPPORTED 


MM PDU/FUNCTION NOT 
SUPPORTED 
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1 6. 1 0.40 New registered area 



The new registered area information element shall be a collection of information elements as defined in table 16.75. 
Table 16.75: New registered area information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


LA timer 


3 


1 


M 




LA 


14 


1 


M 




LACC 


10 


2 





See note 


LANG 


14 


2 





See note 


NOTE: Not used in this version of the present document. 



16.10.41 Proprietary 

Proprietary is an optional, variable length information element and shall be used to send and receive proprietary defined 
information appended to the PDUs. 

The use, the size and the structure of the proprietary information element is outside the scope of the present document 
expect the first octet which shall indicate the owner of the proprietary information element as defined in annex H. 

16.10.41a QAM capabilities 

The QAM capabilities information element shall be a collection of information elements as defined in table 16.76. 
Table 16.76: QAM capabilities information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Value 


Remark 


IVIaximum downlinl< QAIVl 
modulation level (see note) 


3 


1 


M 


OOO2 


Reserved 


OOI2 


1 6-QAM 


01 O2 


64-OAM 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 


QAM fast switching 






M 





QAM fast switching not supported 


1 


QAM fast switching supported 


QAIVl in 25 kHz bandwidth 






M 





QAM in 25 kHz bandwidth not supported 


1 


QAM in 25 kHz bandwidth supported 


QAIVl in 50 kHz bandwidth 






M 





QAM in 50 kHz bandwidth not supported 


1 


QAM in 50 kHz bandwidth supported 


QAIVl in 100 kHz bandwidth 






M 





QAM in 100 kHz bandwidth not supported 


1 


QAM in 100 kHz bandwidth supported 


QAM in 150 kHz bandwidth 






M 





QAM in 150 kHz bandwidth not supported 


1 


QAM in 150 kHz bandwidth supported 


Reserved 


8 




M 




Shall be set to OOOOOOOO2 in the present 
document 


NOTE: If the BS does not understand the value of this element, it should assume the MS supports all 
downlink modulation levels up to the maximum downlink modulation level supported by the BS. 
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16.10.41b Reason for dual watch change by SwMI 

The reason for dual watch change by SwMI information element shall inform the MS of the reason why the SwMI is 
changing the MS's dual watch operation, as defined in table 16.77. 

Table 16.77: Reason for dual watch change by SwMI information element contents 



Information element 


Length 


Value 


Remark 


Reason for dual watch change 
by SwMI 


3 


OOO2 


Dual watch terminated for undefined reason 


OOI2 


Change of dual watch energy economy group 


01 O2 


Reserved 


etc. 


etc. 


III2 


Reserved 



16. 10.42 Reject cause 

The reject cause information element shall indicate what type of rejection has been detected as defined in table 16.78. 

Table 16.78: Reject cause information element contents 



Information element 


Length 


Value 


Remark 


Reject cause 


5 


OOOOO2 


Reserved 


00001 2 


ITSI/ATSI unknown (system rejection) 


0001 O2 


Illegal MS (system rejection) 


00011 2 


LA not allowed (LA rejection) 


001 OO2 


LA unknown (LA rejection) 


001012 


Network failure (cell rejection) 


001 IO2 


Congestion (cell rejection) 


001 II2 


Forward registration failure (cell rejection) 


010002 


Service not subscribed (LA rejection) 


010012 


Mandatory element error (system rejection) 


010102 


Message consistency error (system rejection) 


010112 


Roaming not supported (LA rejection) 


011002 


Migration not supported (system rejection) 


011012 


No cipher KSG (cell rejection) 


011102 


Identified cipher KSG not supported (cell rejection) 


011112 


Requested cipher key type not available (cell rejection) 


100002 


Identified cipher key not available (cell rejection) 


10001 2 


Reserved 


100102 


Ciphering required (cell rejection) 


100112 


Authentication failure (system rejection) 


101002 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 
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1 6. 1 0.43 Request to append LA 

The request to append LA information element shall indicate whether the MS user wants to append the new LA into the 
current registered area or not as defined in table 16.79. 

Table 16.79: Request to Append LA information element contents 



Information element 


Length 


Value 


Remark 


Request to append LA 


1 





No request to append LA to registered area 
(i.e. Registered area to include only this new LA) 


1 


Request to append LA to registered area 



16.10.43a Re-send interval 

The re-send interval information element shall indicate the occasion when the MS should re-send the 
U-MS FREQUENCY BANDS INFORMATON PDU as defined in table 16.80. 

Table 16.80: Re-send interval information element contents 



Information element 


Length 


Value 


Remark 


Re-send interval 


2 


OO2 


Re-sending not needed 


OI2 


Re-send after each ITSI-Attach location update 


IO2 


Re-send after each location update 


II2 


Reserved 



1 6. 1 0.43b Result of dual watch request 

The result of dual watch request information element shall inform the MS of the result of its dual watch request as 
defined in table 16.81. 

Table 16.81 : Result of dual watch request information element contents 



Information element 


Length 


Value 


Remark 


Result of dual watch request 


3 


OOO2 


Request rejected for undefined reason 


OOI2 


Dual watch not supported 


01 O2 


Request accepted with the dual watch energy 
economy group given in the "energy saving 
information" information element 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 



16.10.44 SSI 

The SSI information element shall indicate the ASSI or (V)ASSI that the MS shall use in subsequent contacts with the 
SwMI as defined in table 16.82. It can also be used during registration to explicitly inform the SwMI of the full ITSI 
when used in conjunction with the MCC and MNC. 

Table 16.82: SSI information element content 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See EN 300 392-1 [6], clause 7 
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16.1 0.45 SCCH information 

The SCCH information element shall assign parameters used by the MAC to calculate which CCCH to use when 
common SCCHs are in operation as defined in table 16.83. 

Table 16.83: SCCH information element contents 



Information element 


Length 


Value 


Remark 


SCCH information 


4 


OOOO2 


MS SCCH allocation 


0001 2 


MS SCCH allocation 1 


etc. 


etc. 


IOII2 


IVIS SCCH allocation 1 1 


IIOO2 


Reserved 


etc. 


etc. 


IIII2 


Reserved 



16. 10.46 SCCH information and distribution on 18tln frame 

The SCCH information and distribution on 18th frame information element shall inform the MS of any SCCH 
information and on which of the 4 time slots the MS shall monitor down link information in the case of minimum mode 
as defined in table 16.84. 

Table 16.84: SCCH information and distribution on 18th frame information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


SCCH information 


4 


1 


M 




Distribution on 18th frame 


2 


1 


M 





16.10.47SCK number 

For the SCK number information element refer to EN 300 392-7 [8]. 

1 6. 1 0.47a Start of direct mode operation cause 

Start of direct mode operation cause information element shall indicate the reason for entering direct mode operation as 
defined in table 16.85. 

Table 16.85: Start of direct mode operation cause information element contents 



Information element 


Length 


Value 


Remark 


Start of direct mode 
operation cause 


3 


OOO2 


User initiated mode change 


001 2 


MS initiated mode change due to a potential loss of SwMI 
coverage 


01 O2 


MS initiated mode change due to SwMI load 


0112 


Reserved 


etc. 


etc. 


III2 


Reserved 
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16. 10.48 Status downlink 

The status downlink information element shall indicate the requested service or a response to a request, and the sub-type 
of the D-MM STATUS PDU as defined in table 16.86. 

Table 16.86: Status downlink information element content 



Information element 


Length 


Value 


Remark 


Status downlink 


6 


OOOOOO2 


Reserved 


000001 2 


Change of energy saving mode request 


00001 O2 


Change of energy saving mode response 


000011 2 


Dual watch mode response 


0001 OO2 


Terminating dual watch mode response 


0001 01 2 


Change of dual watch mode request 


0001 IO2 


Reserved (for an energy saving or dual watch purpose) 


0001 II2 


MS frequency bands request 


0010002 


Periodic distance reporting 


001 001 2 


Reserved 


etc. 


etc. 


OOIIII2 


Reserved 


OIOOOO2 


Refer to EN 300 396-5 [24] 


etc. 


etc. 


OIIIII2 


Refer to EN 300 396-5 [24] 


IOOOOO2 


Available for TETRA network and user specific definitions 


etc. 


etc. 


IOIIII2 


Available for TETRA network and user specific definitions 


IIOOOO2 


Reserved 


etc. 


etc. 


IIIIII2 


Reserved 
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16.10.48a status uplink 

Status uplink information element shall indicate the requested service or a response to a request and the sub-type of the 
U-MM STATUS PDU as defined in table 16.87. 

Table 16.87: Status uplink information element content 



Information element 


Length 


Value 


Remark 


Status uplink 


6 


OOOOOO2 


Reserved 


000001 2 


Change of energy saving mode request 


00001 O2 


Change of energy saving mode response 


000011 2 


Dual watch mode request 


0001 OO2 


Terminating dual watch mode request 


0001 01 2 


Change of dual watch mode response 


0001 IO2 


Start of direct mode operation 


0001 II2 


IVIS frequency bands information 


0010002 


Reserved 


etc. 


etc. 


OOIIII2 


Reserved 


OIOOOO2 


Refer to EN 300 396-5 [24] 


etc. 


etc. 


OIIIII2 


Refer to EN 300 396-5 [24] 


IOOOOO2 


Available for TETRA network and user specific definitions 


etc. 


etc. 


IOIIII2 


Available for TETRA network and user specific definitions 


IIOOOO2 


Reserved 


etc. 


etc. 


IIIIII2 


Reserved 



1 6. 1 0.49 Subscriber class 

The subscriber class information element shall subdivide the MS population in up to 16 classes (see definition) 
represented as a bit map as defined in table 16.88. 

Table 16.88: Subscriber class information element 



Information element 


Length 


Value 


Remark 


Class 1 


1 





Not a member of class 1 


1 


IVIember of class 1 


Class 2 


1 





Not a member of class 2 


1 


Member of class 2 


etc. 


1 





etc. 


1 


etc. 


Class 16 


1 





Not a member of class 1 6 


1 


IVIember of class 16 
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16. 10.50 Void 

16.10.51 Type 3/4 element identifier 

The Type 3/4 element identifier information element shall indicate the type of the following Type 3/4 element in the 
PDU as defined in table 16.89. 

Table 16.89: Type 3/4 element identifier information element contents 



Information element 


Length 


Value 


Remark 


Type 3/4 element identifier 


4 


OOOO2 


Reserved for future extension 


OOOI2 


Default group attachment lifetime 


001 O2 


New registered area 


OOII2 


Group identity location demand 


OIOO2 


Group report response 


OIOI2 


Group identity location accept 


011 O2 


DM-MS address, see EN 300 396-5 [24] and EN 300 392-7 [8] 


01112 


Group identity downlink 


10002 


Group identity uplink 


10012 


Authentication uplink, see EN 300 392-7 [8] 


10102 


Authentication downlink, see EN 300 392-7 [8] 


10112 


Extended capabilities 


11002 


Group Identity Security Related Information, see EN 300 392-7 [8] 


11012 


Reserved for any future specified Type 3/4 element 


11102 


Reserved for any future specified Type 3/4 element 


11112 


Proprietary 



16.1 0.52 (V)GSSI 

The (V)GSSI information element shall indicate the (V)GSSI that the MS shall use in subsequent contacts with the 
SwMI as defined in table 16.90. 

Table 16.90: (V)GSSI information element contents 



Information element 


Length 


Value 


Remark 


Visitor Group Short Subscriber Identity 


24 




See EN 300 392-1 [6], clause 7 



16. 10.53 Zero bit 

The Zero bit information element shall be as defined in table 16.91. 

Table 16.91 : Zero bit information element contents 



Information element 


Length 


Value 


Remark 


Zero bit 


1 





This guarantees the backward compatibility to edition 1 
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16.11 Parameters 

16.11.1 Timers 

1 6.11 .1 .1 Timer T351 : Registration response time 

This shall be the maximum time MM is waiting for a response for a registration request. The timer T35 1 value shall be 
10 s. 

1 6.1 1 .1 .2 Timer T352: Energy mode response time 

This shall be the maximum time MM is waiting for a response for an energy saving or dual watch mode request. The 
timer T352 value shall be 30 s. 

1 6.1 1 .1 .3 Timer T353: Attach/Detach response time 

This shall be the maximum time MM is waiting for a response for a U-Attach/Detach Group Identity PDU. The timer 
T353 value shall be 10 s. 

16.11.2 Constants 

1 6.1 1 .2.1 N351 : Maximum system rejection count 

When an MS has received N35 1 registration rejections of type "system rejection" without a successful registration on 
a system, it shall leave the system and shall not attempt to register again on that system until after a power cycle. N351 
shall have a value in the range 1 to 4 with a default value of 4. 
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17 MLE service description 

17.1 Introduction 

This clause describes the services offered by the MLE. 

The assumed underlying protocol is a MLE protocol, which is assumed to be positioned in the lowest sub-layer of 
layer 3 of the air interface stack. 

The MLE services are provided through a set of SAPs, with each SAP corresponding to one type of service user (one 
upper layer 3 protocol). 

The MLE protocol has been designed to hide most of the radio aspects of the air interface, and the resulting MLE 
services are intended to be comparable to non-radio (line) layer 2 protocols. 

NOTE: Identical service definitions should also be used for LSs to allow the use of identical upper layer 3 
protocols in LSs. 

The MLE service boundary is an internal sub-layer boundary that is defined to clarify the description of the air interface 
layer 3. It is not intended to be a testable boundary. Conformance to this service should be achieved by providing 
conformance to one of the assumed MLE protocols. 

1 7.2 Summary of services offered by MLE protocol 

The MLE provides services to MLE service users. These services should be made available through SAPs. This 
relationship is shown in figure 17. L 

Service User 



SAP 



Service Provider 

Figure 17.1 : Relationship between a service user and a service provider 

The entities listed below shall be permitted to use MLE services: 

• Mobility Management (MM) entity (see clause 16); 

• Circuit Mode Control Entity (CMCE) (see clause 14); 

• Subnetwork Dependent Convergence Protocol (SNDCP) entity (see clause 28). 

All of the permitted MLE service users need not be present. However, in order that the MLE services may be requested, 
at least some of the permitted MLE service users should be present. For example, a Vh-D MS may choose not to 
implement the SNDCP entity. The MLE shall not be required to support the MLE service users which are not present. 

The MLE services are represented by the set of MLE service primitives which are available via the various SAPs listed 
in table 17.1. 

Table 17.1 :IV!LE SAPs 



SAP name 


Upper layer 3 protocol (service user) 


Reference 


LMM-SAP 


Mobility Management (MM) 


clauses 17.3.1 and 17.3.2 


LCMC-SAP 


Circuit Mode Control Entity (CMCE) 


clauses 17.3.3 and 17.3.4 


LTPD-SAP 


Subnetwork Dependent Convergence Protocol (SNDCP) 


clauses 17.3.5 and 17.3.6 
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With the exception of the LMM-SAP, the services offered at each SAP should be independent of each other, and the 
service at each of the other SAPs should operate using an independent set of primitives. The LMM-SAP can act as a 
"master SAP", enabling and disabling service provision at the other SAPs. 

The LTPD-S AP may support multiple independent instances of higher protocol (multiple instances of SNDCP, each 
with an independent set of primitives) but each instance must be associated with a different TSI family. All TSI families 
associated with SNDCP within 1 MS/LS shall be associated with a single instance of MM protocol. 

NOTE: Multiple TSI families are the normal situation on the TETRA infrastructure side. Most MSs contain only 
one TSI family, but multiple TSI families may co-exist in one MS (see EN 300 392-1 [6], clause 7). 

Figure 17.2 shows the service relationships relating to the MLE services. 



MM 



CMCE 



SNDCP 



SNDCP 



CMCE 



MM 



SAPS 




-^ 



data transfer 
relationships 



LTPD 



(LCMCy 



KLMM) 



MLE (and lower layers) i MLE (and lower layers) 

Mobile Side Air Interface Infrastructure Side 

Figure 17.2: Services relationships offered by the IVILE in the air interface 



17.3 Service descriptions 



The following service descriptions describe the MLE services provided to the higher layers in the MS protocol stack. 
The services are described for the protocol model purposes and present no testable requirements. 

1 7.3.1 Service state diagram for tine LIVIIVI-SAP 

The primitives provided by the MLE to the MM entity shall be as shown in table 17.2. 

Table 17.2: Primitives and parameters at the LMM-SAP 



Primitives generic name 


Specific name 


Parameters 


MLE-ACTIVATE 


request 


List of MCC 
List of MNC 


confirnn 


Registration required 
LA 


indication 


- 


MLE-ACTIVITY 


request 


Sleep mode 


MLE-BUSY 


request 


- 


MLE-CANCEL 


request 


Handle 


MLE-CONFIGURE 


request 


Periodic reporting timer 


MLE-CLOSE 


request 


- 


MLE-DEACTIVATE 


request 


- 


MLE-DISABLE 


Request 


Permitted services 


MLE-ENABLE 


Request 


- 


MLE-IDENTITIES 


request 


ISSI 
ASSI 

Attached GSSIs 
Detached GSSIs 


MLE-IDLE 


request 


- 
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Primitives generic name 


Specific name 


Parameters 


MLE-INFO 


request 


Subscriber class 

SCCH configuration 

Energy economy mode configuration 

IVIinimum mode configuration 

Dual watch mode configuration 


indication 


Broadcast parameters 
Subscriber class match 


MLE-LINK 


request 


MCC 
MNC 
List of LA 


indication 


MCC 

MNC 

LA 

Registration type 

Security parameters 


MLE-OPEN 


request 


- 


MLE-PREPARE 


request 


SDU 

Handle 

Layer 2 service 

PDU priority 

Stealing permission 

Stealing repeats flag 


confirm 


SDU 
Handle 


MLE-REPORT 


indication 


Handle 
Transfer result 


MLE-UNITDATA 


request 


SDU 
Handle 
Address type 
Address 
layer 2 service 
PDU priority 
Stealing permission 
Stealing repeats flag 
Encryption flag 
Null PDU, (see note) 


indication 


SDU 
Handle 

Received address 
Received address type 


MLE-UPDATE 


request 


MCC 

MNC 

RA 

Registration result 


NOTE: When a null PDU is indicated then the PDU priority shall be the lowest value and stealing shall not be 
permitted. The other parameters are not applicable with a null PDU. 
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The transactions between the states shall be as shown in figure 17.3. 



MLE-DEACTIVATE 
request 




MLE-UPDATE request 
MLE-LINK request 
MLE-LINK indication 
IVILE-ACTIVATE indication 
IVILE-CANCEL request 
IVILE-INFO indication 



MLE-UNITDATA request 
MLE-UNITDATA indication 
IVILE-REPORT indication 
IVILE-IDENTITIES request 
IVILE-INFO request 
MLE-CONFIGURE request 



MLE-OPENj 
request I 



MLE-CLOSE request 




MLE-ACTIVITY request 
MLE-UNITDATA request 
MLE-UNITDATA indication 
MLE-REPORT indication 
MLE-OPEN request 
MLE-BUSY request 
MLE-IDLE request 
MLE-PREPARE request 
MLE-PREPARE confirm 
MLE-IDENTITIES request 
MLE-INFO request 
MLE-CONFIGURE request 



Figure 17.3: LMM-SAP state transition diagram 

1 7.3.2 Service primitives for tine LMM-SAP 

MLE-ACTIVATE request: this shall be used as a request to initiate the selection of a cell for communications. The 
request shall always be made after power on and may be made at any time thereafter. 

MLE-ACTIVATE confirm: this shall be used as a confirmation to the MM entity that a cell has been selected with the 
required characteristics. 

MLE-ACTIVATE indication: this shall be used as an invitation to the MM to react as no suitable cell is available. 

MLE-ACTIVITY request: this shall be used by the MM entity to inform the MLE that the MS must "stay alive" or if 
sleeping is permitted. It is used during a signalling exchange with the SwMl, which requires a layer 3 response. 

MLE-BUSY request: this shall be used by the MM entity to indicate to MLE that a MM protocol exchange is in 
progress. 

MLE-CANCEL request: this may be used by the MM to delete a previous request issued but not yet transmitted. The 
ability to cancel shall be removed when the MLE-REPORT indication is received, indicating transmission of the MM 
PDU. 

MLE-CLOSE request: this shall be used by the MM entity to instruct the MLE to remove access to communication 
resources for the other layer 3 entities, but keeping access to the communication resources for the MM entity. 

MLE-CONFIGURE request: this primitive shall be used by the MM entity to pass inter layer management 
information relating to mobility management. 
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MLE-DEACTIVATE request: this shall be used by the MM entity to request the de-activation of all MLE procedures 
and to return to the NULL state. No communication resources are available for use after this primitive has been issued. 

MLE-DISABLE request: this primitive shall be used by the MM entity to request MLE to put the MS into the 
temporarily disabled state. 

MLE-ENABLE request: this primitive shall be used by the MM entity to request MLE to recover the MS from the 
temporarily disabled state. 

MLE-IDENTITIES request: this primitive shall be used to transfer the identities that have been received from the 
SwMI to the MLE, and layer 2. 

MLE-IDLE request: this shall be used by the MM entity to indicate to MLE that a MM protocol exchange has 
completed. 

MLE-INFO request: this primitive shall be used to transfer control parameters received from the SwMI to the MLE 
and layer 2. These control parameters include information on energy economy modes, control channel configurations 
and subscriber class. 

MLE-INFO indication: this primitive shall be used by MLE to inform the MM of a change in system broadcast 
parameters or to indicate whether there is any match between the subscriber class being broadcast by the SwMI and the 
subscriber class of the MS. 

MLE-LINK request: this shall be used by the MM entity to request that MLE select a specified MCC, MNC and 
possible LA. 

MLE-LINK indication: this shall be used by the MLE to indicate to the MM entity that the MS has selected or is about 
to select a cell and registration is needed on the new cell, or the MS is required to re-register on the current cell. 

MLE-OPEN request: this shall be used by the MM entity to instruct the MLE to provide access to communication 
resources for other layer 3 entities after successful registration. 

MLE-PREPARE request: this shall be used by the MM entity to instruct the MLE to forward register during 
announced type 1 cell reselection. 

MLE-PREPARE confirm: this shall be used by the MLE to confirm forward registration during announced type 1 cell 
reselection. 

MLE-REPORT indication: this shall be used by the MLE to report on the completion of an MLE-UNITDATA 
request procedure. The result of the transfer attempt is passed as a parameter. Errors detected during the 
MLE-UNITDATA request procedure are indicated using this primitive. 

MLE-UNITDATA request: this shall be used by the MM entity to request a data transmission A parameter indicates 
which layer 2 service is required. 

MLE-UNITDATA indication: this shall be used by the MLE to pass to the MM entity data which has been received 
from the SwMI. 

MLE-UPDATE request: this shall be used by the MM entity to inform the MLE about new criteria concerned with the 
monitoring of other possible cells. 
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1 7.3.3 Service state diagram for tine LCMC-SAP 

The primitives provided by the MLE to the CMCE shall be as shown in table 17.3. 

Table 17.3: Primitives and parameters at the LCIVIC-SAP 



Generic name 


Specific name 


Parameters 


MLE-ACTIVITY 


request 


Call state 


MLE-BREAK 


indication 


- 


MLE-BUSY 


indication 


- 


MLE-CANCEL 


request 


Handle 


MLE-CLOSE 


indication 


- 


MLE-CONFIGURE 


request 


Endpoint identifier 
Channel change accepted 
Channel change handle 
Call release 
Encryption flag 
Circuit mode type 
Simplex/duplex 
Add temporary GSSI 
Delete temporary GSSI 
Tx grant 
Switch U Plane 


MLE-CONFIGURE 


indication 


Endpoint identifier 

Channel change response required 

Channel change handle 

Reason for configuration indication 

Conflicting endpoint identifier 


MLE-DISABLE 


indication 


Permitted services 


MLE-ENABLE 


indication 


- 


MLE-IDENTITIES 


request 


List of GSSIs 


MLE-IDLE 


indication 


- 


MLE-INFO 


indication 


Broadcast parameters 
Subscriber class match 


MLE-OPEN 


indication 


IVICC (current network) 
MNC (current network) 


MLE-REOPEN 


indication 


- 


MLE-REPORT 


indication 


Handle 

Transfer result 

Channel change response required 

Channel change handle 


MLE-RESTORE 


request 


SDU 

Handle 

layer 2 service 

PDU priority 

Stealing permission 

Stealing repeats flag 


confirm 


SDU 
Handle 


MLE-RESUME 


indication 


IVICC (current network) 
MNC (current network) 
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Generic name 


Specific name 


Parameters 


MLE-UNITDATA 


request 


SDU 
Handle 

Endpoint identifier 
Link identifier 
layer 2 service 
PDU priority 
Quality of Service 
Stealing permission 
Stealing repeats flag 


indication 


SDU 

Handle 

Endpoint identifier 

Link identifier 

Received TETRA address (ITSI/GTSI) 

Received address type 

Channel change response required 

Channel change handle 



The state transitions visible at this SAP shall be as shown in figure 17.4. 

MLE-CLOSE indication 




MLE-ACTIVITY request 
MLE-BUSY indication 
MLE-IDLE indication 
MLE-INFO indication 
MLE-CANCEL request 
MLE-UNITDATA request 
MLE-UNITDATA indication 
MLE-REPORT indication 
MLE-RESTORE request 
MLE-RESTORE confirm 
MLE-IDENTITIES request 
MLE-CONFIGURE indication 
MLE-CONFIGURE request 



MLE-CONFIGURE indication 
MLE-CONFIGURE request 




MLE-BREAK indication 



MLE-RESUME indication 
MLE-REOPEN indication 



Figure 17.4: State transition diagram of LCIUIC-SAP 



1 7.3.4 Service primitives for LCMC-SAP 



MLE-ACTIVITY request: this primitive shall be used by the CMCE to inform the MLE of the state of any circuit 
mode call(s). 

MLE-BREAK indication: this primitive shall be used by the MLE to inform the CMCE that access to the 
communication resources is temporarily unavailable and that the data transfer service cannot be used. 

MLE-BUSY indication: this shall be used by the MLE to inform the CMCE that a MM protocol exchange is in 
progress. 

MLE-CANCEL request: this primitive shall be used by the CMCE to delete a previous request issued but not yet 
transmitted. The ability to cancel shall be removed when the MLE-REPORT indication is received, indicating 
successful or first complete transmission of the CMCE PDU. 
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MLE-CLOSE indication: this primitive shall be used by the MLE to indicate to the CMCE that access to the 
communications resources has been removed and that data transfer service cannot be used. 

MLE-CONFIGURE request: this primitive shall be used to pass inter layer management information relating to 
circuit mode calls, e.g. whether Tx grant has been given, type of traffic etc. 

MLE-CONFIGURE indication: this primitive shall be used to pass inter layer management information relating to 
circuit mode calls and packet data conflicts. 

MLE-DISABLE indication: this primitive shall be used by the MLE entity to instruct the CMCE entity to enter the 
temporarily disabled state. 

MLE-ENABLE indication: this primitive shall be used by the MLE entity to instruct the CMCE entity to recover from 
the tamporarily disabled state. 

MLE-IDENTITIES request: this primitive shall be used by the CMCE to inform the MLE and layer 2 of a change to 
the list of group identities. 

MLE-IDLE indication: this shall be used by the MLE to inform the CMCE that a MM protocol exchange has 
completed. 

MLE-INFO indication: this primitive shall be used by MLE to inform the CMCE of a change in system broadcast 
parameters or to indicate whether there is any match between the subscriber class being broadcast by the SwMI and the 
subscriber class of the MS. 

MLE-OPEN indication: this primitive shall be used by the MLE to inform the CMCE that it has access to the 
communication resources and that the data transfer service can be used. 

MLE-REOPEN indication: this primitive shall be used by the MLE to inform the CMCE that access to the 
communication resources is once again available. MLE-REOPEN indication indicates the failure of current call 
restoration to CMCE but does not prevent CMCE from restoring other circuit-mode calls. The data transfer service can 
now be used. 

MLE-REPORT indication: this shall be used by the MLE to report on the completion of an MLE-UNITDATA 
request procedure. The result of the transfer attempt shall be passed as a parameter. 

MLE-RESTORE request: this primitive shall be used by the CMCE to restore a call after a successful cell reselection. 

MLE-RESTORE confirm: this primitive indicates the success or failure of call restoration to the CMCE as a result of 
a previously issued MLE-RESTORE request. 

MLE-RESUME indication: this primitive shall be used by the MLE to inform the CMCE that access to the 
communication resources is once again available. The data transfer service can now be used and the CMCE may 
attempt to restore any circuit mode calls. 

MLE-UNITDATA request: this primitive shall be used by the CMCE to send unconfirmed data to a peer entity on the 
TETRA infrastructure side. Parameter indicates which layer 2 service is required. 

MLE-UNITDATA indication: this primitive shall be used by the MLE to pass to the CMCE entity data which has 
been received from a peer entity on the TETRA infrastructure side. 
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1 7.3.5 Service state diagram for tine LTPD-SAP 

The primitives provided by the MLE to the SNDCP entities shall be as shown in table 17.4. 

Table 17.4: Primitives and parameters at the LTPD-SAP 



Generic name 


Specific name 


Parameters 


MLE-ACTIVITY 


request 


Sleep mode 


MLE-BREAK 


indication 


- 


MLE-BUSY 


indication 


- 


MLE-CANCEL 


request 


Handle 


MLE-CLOSE 


indication 


- 


MLE-CONFIGURE 


request 


Channel change accepted 

Channel change handle 

Call release 

Endpoint identifier 

Encryption flag 

MS default data priority 

Layer 2 data priority lifetime 

Layer 2 data priority signalling delay 

Data priority random access delay factor 

Data class information 

Schedule repetition information 

SNDCP status 


MLE-CONFIGURE 


indication 


Endpoint identifier 

Channel change response required 

Channel change handle 

Reason for configuration indication 

Conflicting endpoint identifier 


MLE-CONNECT 


request 


Address 

Endpoint identifier 
Link identifier 
Resource request 
PDU priority 
Quality of Service 
Encryption flag 
Setup report 


indication 


Address 

Endpoint identifier 

New endpoint identifier 

Link identifier 

Quality of Service 

Encryption flag 

Channel change response required 

Channel change handle 

Setup report 


response 


Address 

Endpoint identifier 
Link identifier 
PDU priority 
Stealing permission 
Quality of Service 
Encryption flag 
Setup report 


confirm 


Address 

Endpoint identifier 

Link identifier 

Quality of Service 

Encryption flag 

Channel change response required 

Channel change handle 

Setup report 
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Generic name 


Specific name 


Parameters 


MLE-DISABLE 


indication 


Permitted services 


MLE-DISCONNECT 


request 


Endpoint identifier 
Link identifier 
PDU priority 
Encryption flag 
Report 


indication 


Endpoint identifier 

New endpoint identifier 

Link identifier 

Encryption flag 

Channel change response required 

Channel change handle 

Report 


MLE-ENABLE 


indication 


- 


MLE-INFO 


indication 


Broadcast parameters 
Subscriber class match 
Schedule timing prompt 


MLE-IDLE 


indication 


- 


MLE-OPEN 


indication 


IVICC (current network) 
MNC (current network) 


MLE-RECEIVE 


indication 


Endpoint identifier 

Received TETRA address (ITSI/GTSI) 

Received address type 


MLE-RECONNECT 


request 


Endpoint identifier 
Link identifier 
Resource request 
PDU priority 
Encryption flag 
Stealing permission 


confirm 


Endpoint identifier 
New endpoint identifier 
Link identifier 
Encryption flag 
Report 
Reconnection result 


indication 


Endpoint identifier 
New endpoint identifier 
Link identifier 
Encryption flag 
Report 
Reconnection result 


MLE-RELEASE 


request 


Link identifier 


MLE-REPORT 


indication 


Handle 
Transfer result 


confirm 


Quality of Service 


MLE-RESUME 


indication 


MCC (current network) 
IVINC (current network) 
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Generic name 


Specific name 


Parameters 


MLE-UNITDATA 


Request 


SDU 

Handle 

Layer 2 service 

Unacknowledged basic link repetitions 

PDU priority 

Endpoint identifier 

Link identifier 

Stealing permission 

Stealing repeats flag 

Channel advice flag 

Data class information 

Data priority 

MLE data priority flag 

Packet data flag 

Scheduled data status 

IVIaximum schedule interval 

PCS flag 


Indication 


SDU 

Endpoint identifier 

Link identifier 

Received TETRA address (ITSI/GTSI) 

Received address type 

Channel change response required 

Channel change handle 



The state transitions visible at the LTPD-SAP should be as shown in figure 17.5. 



MLE-ACTIVITY request 
MLE-REPORT indication 
MLE-UNITDATA request 
MLE-UNITDATA indication 
MLE-BREAK indication 
MLE-BUSY indication 
MLE-CANCEL request 
MLE-CONFIGURE request 
MLE-CONFIGURE indication 
MLE-CONNECT request 
MLE-CONNECT indication 
MLE-CONNECT response 
MLE-CONNECT confirm 
MLE-DISCONNECT request 
MLE-DISCONNECT indication 
MLE-IDLE indication 
MLE-INFO indication 
MLE-RECONNECT request 
MLE-RECONNECT indication 
MLE-RECONNECT confirm 
MLE-RELEASE request 
MLE-RESUME indication 




MLE-OPEN indication 



MLE-CLOSE indication 



Figure 17.5: State transition diagram of LTPD-SAP 
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1 7.3.6 Service primitives for LTPD-SAP 

The service primitives at the LTPD-SAP shall be the following: 

MLE-ACTIVITY request: this primitive shall be used by the SNDCP to inform the MLE that the MS must "stay 
alive" or if sleeping is permitted. It is used during MS initiated signalling exchanges with the SwMI. 

MLE-BREAK indication: this shall be used by the MLE to inform the SNDCP entity that the resources needed for 
communication are temporarily not available. This can be due to a lower layer failure, or due to a MLE controlled cell 
change. 

MLE-BUSY indication: this shall be used by the MLE to inform the SNDCP entity that a MM protocol exchange is in 
progress. 

MLE-CANCEL request: this primitive shall be used by the SNDCP to delete a previous request issued but not yet 
transmitted. The ability to cancel shall be removed when the MLE-REPORT indication is received, indicating 
successful or first complete transmission of the SNDCP PDU. 

MLE-CLOSE indication: this shall be used by the MLE to indicate to the SNDCP entity that access to the 
communications resources has been removed and the SNDCP entity is not permitted to communicate with its peer 
entity. 

MLE-CONFIGURE request: this primitive shall be used by the SNDCP entity to pass inter layer management 
information relating to packet data. 

MLE-CONFIGURE indication: this primitive shall be used to pass inter layer management information relating to 
circuit mode calls and packet data conflicts. 

MLE-CONNECT request: this primitive shall be used by the SNDCP entity to convey QoS parameters used in the 
advanced link set up. It also shall be used to trigger the MLE to reset the advanced link. It also applies as a cancel 
request which deletes previous requests issued and not yet transmitted. 

MLE-CONNECT indication: this primitive shall be used by the MLE entity to inform the SNDCP entity that the 
establishment of an advanced link with a certain quality of service or the reset of the current advanced link has been 
requested. 

MLE-CONNECT response: this primitive may be used by the SNDCP entity to accept the establishment or reset of 
the advanced link with a certain quality of service. According to the available resources, the value of the service 
parameters may be modified (lower grade of service) in the response. In such a case the advanced link characteristics 
will match these new features. 

MLE-CONNECT confirm: this primitive shall be used by the MLE entity to inform the SNDCP entity that the 
establishment or reset of the advanced link has been completed with a certain quality of service as indicated in the 
confirm primitive. 

MLE-DISABLE indication: this primitive shall be used by the MLE entity to instruct the SNDCP entity to enter the 
temporarily disabled state. 

MLE-DISCONNECT request: this primitive shall be used by the SNDCP entity to trigger MLE to disconnect the 
advanced link. It also applies as a CANCEL Request which deletes previous requests issued and not yet transmitted 

MLE-DISCONNECT indication: this primitive shall be used by the MLE entity to inform the SNDCP entity on 
advanced link disconnection for any reason. 

MLE-ENABLE indication: this primitive shall be used by the MLE entity to instruct the SNDCP entity to recover 
from the temporarily disabled state. 

MLE-IDLE indication: this shall be used by the MLE to inform the SNDCP entity that a MM protocol exchange has 
completed. 

MLE-INFO indication: this primitive shall be used by MLE to inform the SNDCP of a change in system broadcast 
parameters or to indicate whether there is any match between the subscriber class being broadcast by the SwMI and the 
subscriber class of the MS. 
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MLE-OPEN indication: this primitive shall be used by the MLE to inform the SNDCP that it has access to the 
communication resources and that the data transfer service can be used. 

MLE-RECEIVE indication: this primitive shall be used by the MLE entity to inform the SNDCP entity that the 
reception of data from the peer entity on the LLC has started or is ongoing. This primitive is valid for SwMI only. 

MLE-RECONNECT request: this primitive shall be used by the MS SNDCP entity after cell reselection to request the 
reconnection of the advanced link. 

MLE-RECONNECT confirm: this primitive shall be used by the MS MLE entity to inform the SNDCP entity of the 
success or failure of an attempt to reconnect the advanced link. 

MLE-RECONNECT indication: this primitive shall be used by the SwMI MLE entity to inform the SNDCP entity of 
the success or failure of an attempt by a MS to reconnect an advanced link. 

MLE-RELEASE request: this primitive shall be used by the MS SNDCP entity to request the local disconnection of 
an advanced link. 

MLE-REPORT indication: this shall be used by the MLE to report on the completion of a MLE-UNITDATA request 
procedure. The result of the transfer attempt shall be passed as a parameter. Errors detected during the 
MLE-UNITDATA request procedure shall be indicated using this primitive. 

MLE-RESUME indication: this shall be used to indicate that a temporary break in access to the communications 
resources has been recovered. All previous MLE associations between peer MLE entity have been successfully 
recovered. 

MLE-UNITDATA request: this shall be used by the SNDCP entity to send data to a peer entity. Parameters indicate 
whether layer 2 acknowledged or unacknowledged service is required. 

MLE-UNITDATA indication: this shall be used by the MLE to pass to the SNDCP entity data which has been 
received from a peer entity. 

17.3.7 Void 

17.3.8 Void 

17.3.9 Parameter summary 

The following list summarizes the parameters used in the primitives described in this clause. 

• Add temporary GSSI = 

GSSI. 

• Address = 

TETRA address (ISSI,ASSI or USSI). 

• Address type = 

individual short subscriber identity (ISSI); 
aliased short subscriber identity (ASSI); 
unexchanged short subscriber identity (USSI). 

• ASSI = 

TETRA address. 

• Attached GSSIs = 

TETRA address. 
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Broadcast parameters = 

Broadcast information extracted from SYSINFO PDU. Refer to clauses 18.4.2.2 and 21.4.4.1. 
Call release = 

true; 

false. 
Call state = 

idle; 

group call with transmit permission; 

group call without transmit permission; 

individual call with transmit permission; 

individual call without transmit permission. 
Channel advice flag = 

channel advice not requested; 

channel advice requested. 
Channel change accepted = 

accept; 

reject; 

ignore. 
Channel change handle = 

an identifier of a "channel change response required" request. 
Channel change response required = 

true; 

false. 
Circuit mode type = 

speech (TCH/S); 

unprotected data (TCH/7,2); 

low protection data (TCH/4,8), N = 1 ; 

low protection data (TCH/4,8), N = 4 

low protection data (TCH/4,8), N = 8 

high protection data (TCH/2,4), N = 1 ; 

high protection data (TCH/2,4), N = 4; 

high protection data (TCH/2,4), N = 8. 
Conflicting endpoint identifier = 

conflicting radio resource identifier. 
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• Data class information = 

Background class data; 
Telemetry class data; 
Real-time class data; 
other data (see note). 
NOTE 1: In an implementation, the "other data" may be subdivided into multiple classes. 

• Data priority = 

nine possible values, to 7 and "undefined". 

• Data priority random access delay factor = 

eight possible values, to 7. 

• Delete temporary GSSI = 

GSSI. 

• Detached GSSIs = 

TETRA address(es). 

• Dual watch mode configuration = 

a set of group (0 to 7), start frame (1 to 18) and start multiframe (1 to 60). 

• Encryption flag = 

on; 
off. 

• Endpoint identifier = 

radio resource identifier. 

• Energy economy mode configuration = 

a set of group (0 to 7), start frame (1 to 18) and start multiframe (1 to 60). 

• FCS flag= 

use FCS; 

do not use FCS. 

• Handle 

a local SDU identifier. 

• ISSI = 

TETRA address. 

• Layer 2 data priority lifetime = 

a value ranging from 2 to 126 multiframes. 

• Layer 2 data priority signalling delay = 

a value ranging from 6 to 90 TDM A frames. 
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Layer 2 service = 

acknowledged request; 

acknowledged response; 

unacknowledged. 

Link identifier = 

A local identifier of the layer 2 basic link, a specified advanced link or an unspecified (i.e. any) advanced 
link. 

ListofGSSIs = 

TETRA address(es). 
List of LA. 
LA. 
Maximum schedule interval = 

number of timeslot durations (5 to 834). 
MLE data priority flag = 

MLE data priority signalling not required; 

MLE data priority signalling required. 
Minimum mode configuration = 

frame 18 slot (1 to 4). 
MCC (see EN 300 392-1 [6], clause 7). 
MNC (see EN 300 392-1 [6], clause 7). 
MS default data priority = 

nine possible values, to 7 and "not applicable". 

New endpoint identifier: 

a new endpoint identifier shall refer to a new resource allocation (typically in addition to an existing 
resource allocation). 

Null PDU = 

a null PDU is due to sending; 

an SDU is due to sending. 
Packet data flag = 

PDU does not contain packet data; 

PDU contains packet data. 
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• Permitted services = 

none; or 

a list of one or more of : 

■ ambience listening; 

LIP protocol via CMCE (see TS 100 392-18-1 [19]). 

• PDU priority = 

eight possible values, to 7. 

• Periodic reporting timer = 

no reporting / stop reporting; 
values 15 s to 31 min 45 s. 

• Quality of Service (QoS) = 

A set of: 

■ Throughput; and 

■ Original or extended advanced link; and 

■ Acknowledged advanced link window size (1 to 15); and 

■ Maximum number of TL-SDU retransmissions (0 to 7); and 

■ Maximum number of segment retransmissions (0 to 15). 

• RA = 

a set of one or more LAs. 

• Reason for configuration indication = 

reception stopped; 
transmission stopped; 
usage marker mismatch; 
loss of radio resources; 
recovery of radio resources. 

• Received TETRA address = 

TETRA address (ITSI or GTSI). 

• Received address type = 

individual allocated identity (ITSI); 
individual un-exchanged identity (ITSI); 
group (GTSI). 
NOTE 2: The individual un-exchanged identity is valid only in some migration PDUs, refer to clause 23.4.1.2.5. 
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Reconnection result = 

success; 

reject. 
Registration type = 

normal; 

forward; 

periodic. 
Registration required = 

true; 

false. 
Registration Result = 

success; 

Cell rejection; 

LA rejection; 

system rejection; 

forward registration failure; 

temporary registration. 
Resource request = 

amount of data available for sending, refer to clause 28.3.4.2 a). 
Report 

report shall generally indicate the progress of information transfer. Refer to clause 20.2.4.57. 
Set-up report = 

this shall be used to report on the setup phase of an advanced link. 
SCCH configuration = 

Otoll. 
Schedule repetition information = 

set of NSAPI (1 to 14), "start-stop flag" (start or stop) and "schedule repetition period" (4 to 706). 
Schedule timing prompt = 

NSAPI (1 to 14). 
Scheduled data status = 

not scheduled 

initial scheduled data; 

scheduled data. 
SDU. 
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Security parameters = 

Security related broadcast information extracted from SYSINFO PDU. Refer to see EN 300 392-7 [8]. 
Simplex/duplex = 

simplex; 

duplex. 
Sleep mode = 

stay alive; 

sleep permitted. 
SNDCP status = 

idle, standing-by or ready. 
Stealing permission = 

steal immediately; 

steal when convenient; 

stealing not required. 
Stealing repeats flag = 

set; 

not set. 
Subscriber class 

a set of classes 1 to 16. 
Subscriber class match = 

true; 

false. 
Switch U-plane = 

on; 

off. 
Transfer result = 

success, more data in the LLC buffer; 

success, LLC buffer empty; 

failure, data item removed from LLC buffer; 

transfer rejected due to an emergency call. 
Tx-grant = 

true; 

false. 
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Unacknowledged basic link repetitions 
to 5. 
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18 MLE protocol 

18.1 Introduction 

This clause defines the protocol for the V+D MLE. This shall be the lowest sub-layer of the network layer as described 
in EN 300 392-1 [6]. It may be used to provide sub-network services to higher network layer entities at the air interface 
according to the MLE service description (see clause 17). This clause defines the MLE protocol functions required for 
MS operation. 

This clause specifies: 

• the protocol procedures; 

• the protocol services; 

• the PDUs and associated elements. 

See clause 17 for the MLE service description (SAPs, services and primitives). 

1 8.2 Overview of the sub-layer 

The MLE protocol should be used to mask mobility and radio resources from the higher entities. 

It shall provide a sub-network dependent protocol (convergence) and a sub-network access protocol to the Vh-D layer 2 
(see clause 20). 

18.2.1 Protocol environment 

The Vh-D MLE shall be the layer 3, sub-layer 3.1 which provides services to the layer 3, sub-layer 3.2, as shown in 
figure 18.1. This protocol shall provide services to the following higher entities: 

• MM entity (see clause 16); 

• CMCE entity (see clause 14); 

• SNDCP entity (see clause 28). 

The MLE services shall be represented by the MLE service primitives which shall apply to the following SAPs: 

• LCMC-SAP for CMCE; 

• LTPD-SAP for SNDCP; and 

• LMM-SAP for MM. 

The services offered at the MM SAP may interact with the services offered at the CMCE and SNDCP SAPs. 

The underlying protocol should be the Vh-D layer 2 (see clauses 22 and 23). 

The MLE protocol may also interface to the Lower Layer Management Entity (LLME) and the interface is defined by 
the C-S AP. However, the exact implementation of the interface is outside the scope of the present document. 

The protocol architecture can be similar on the BS side of the air interface. 
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MM 



CMCE 



LMM-SAP 



o- 



SNDCP 



LCMC-SAP 



■o- 



Sublayer 3.2 



LTPD-SAP 



o- 



Layer 3 



MLE 



TLA-SAP 



D- 



TLB-SAP 



D- 



Sublayer 3.1 



TLC-SAP 



D- 



Layer 2 



Figure 18.1 : The MLE (sub-layer 3.1) in the MS protocol stack 



The MS-MLE shall establish the basis for communication with a cell (BS) by camping on the cell and the MS-MLE 
shall check the quality using the information received from the layer 2. Once the cell has been found suitable by the 
MS-MLE, the MM entity may intervene in order to register the MS. When the cell has been registered, the MS is said to 
be attached and the MLE can now offer data transfer services to the CMCE and SNDCP entities as well. Data transfer 
shall be regulated by the MM entity which may allow access for MM only or for all entities. 

The MLE shall perform surveillance of the quality of the radio communication path. It may report any break or loss of 
the path and, when necessary it should try to re-establish the communication with the same or another BS in either the 
same or a different LA. 

1 8.2.2 Services ancd primitives offerecj by tine MLE to tine MM entity 

The services and primitives offered to the MM entity are described in clause 17. 
The services offered shall be: 

a) activation of MLE procedures: 

MLE- ACTIVATE request/confirm/indication. 

b) opening of link access to other layer 3 entities: 

MLE-OPEN request. 

c) data transfer: 

MLE-UNITDATA request/indication; 
MLE-REPORT indication. 

d) closing the access to other entities: 

MLE-CLOSE request. 

e) deactivation of the MLE procedures: 

MLE-DEACTIVATE request. 
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f) information on a network, cell or LA: 

MLE-LINK request/indication. 

g) updating current registered area: 

MLE-UPDATE request, 
h) cancellation of issued primitive requests: 

MLE-CANCEL request, 
i) informing MLE that MM signalling exchange is in progress: 

MLE-BUSY request, 
j) informing MLE that MM signalling exchange has completed: 

MLE-IDLE request, 
k) performing forward registration during cell reselection: 

MLE-PREPARE request/confirm. 
1) exchange of information between layers: 

MLE-IDENTITIES request; 

MLE-INFO request/indication. 
m) requesting temporary disablement: 

MLE-DISABLE request; 
n) requesting recovery from temporary disablement 

MLE-ENABLE request. 

1 8.2.3 Services and primitives offered by tine MLE to tine CMCE entities 

The services and primitives offered to the CMCE entity are described in clause 17. 
The services offered shall be: 

a) indication that access to resources is enabled: 

MLE-OPEN indication. 

b) indication that access to resources is disabled: 

MLE-CLOSE indication. 

c) indicating a temporary break in the access to the communication resources: 

MLE-BREAK indication. 

d) indicating resumption (or reopening) in the access to the communication resources: 

MLE-RESUME indication; 
MLE-REOPEN indication. 

e) restoration of circuit mode calls after cell reselection: 

MLE-RESTORE request/confirm. 
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f) data transfer: 

MLE-UNITDATA request/indication; 
MLE-REPORT indication. 

g) cancellation of issued primitive requests: 

MLE-CANCEL request, 
h) exchange of information between layers: 

MLE-CONFIGURE request; 

MLE-CONFIGURE indication; 

MLE-IDENTITIES request; 

MLE-INFO indication. 
i) indicating that MM signalling exchange is in progress: 

MLE-BUSY indication. 
j) indicating that MM signalling exchange has completed: 

MLE-IDLE indication, 
k) indicating that CMCE shall become temporarily disabled: 

MLE-DISABLE indication. 
1) indicating that CMCE shall recover from temporary disablement: 

MLE-ENABLE indication. 

1 8.2.4 Services and primitives offered by tine MLE to tine SNDCP entity 

The services and primitives offered to the SNDCP entity are described in clause 17. 
The service offered shall be: 

a) indication that access to resources is enabled: 

MLE-OPEN indication. 

b) indication that access to resources is disabled: 

MLE-CLOSE indication. 

c) indicating a temporary break in the access to the communication resources: 

MLE-BREAK indication. 

d) indicating resumption in the access to the communication resources: 

MLE-RESUME indication. 

e) advanced link setup/ advanced link reset: 

MLE-CONNECT request/indication/response/confirm. 

f) advanced link disconnection: 

MLE-DIS CONNECT request/indication; 
MLE-RELEASE request. 
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g) data transfer: 

MLE-UNITDATA request/indication; 

MLE-RECEIVE indication; 

MLE-REPORT indication, 
h) exchange of information between layers: 

MLE-CONFIGURE request; 

MLE-CONFIGURE indication; 

MLE-INFO indication. 
i) advanced link reconnection: 

MLE-RECONNECT request/indication/confirm, 
j) indicating that MM signalling exchange is in progress: 

MLE-BUSY indication, 
k) indicating that MM signalling exchange has completed: 

MLE-IDLE indication. 
1) cancellation of issued primitive requests: 

MLE-CANCEL request. 

18.2.5 Void 

1 8.2.6 Services and primitives offered by layer 2 to MLE 

Layer 2 shall provide the MLE with different services, which enable the MLE to provide the services requested by its 
services users. The following primitives are defined for that purpose. 

On the TLA-SAP the following services and primitives should be available, depending on the supported services (see 
clause 20 for service definitions): 

a) establishing a data link connection by using the LLC advanced link mechanism: 

TL-CONNECT request/indication/response/confirm. 

b) transfer of data using a layer 2 acknowledged service: 

TL-DATA request/indication/response/confirm. 

c) disconnection of an established data link connection, i.e. an LLC advanced link: 

TL-DISCONNECT request/indication/confirm. 

d) transfer of data using a layer 2 unacknowledged service: 

TL-UNITDATA request/indication. 

e) receive report information on the progress of issued request primitives and unrecoverable transmission errors 
detected in the data link: 

TL-REPORT indication. 

f) cancellation of issued request primitives: 

TL-CANCEL request. 



£75/ 



41 2 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

g) release or loss of radio resources: 

TL-RELEASE request; 

TL-RELEASE indication (optional). 

On the TLB-SAP the following services and primitives should be available, see clause 20 for service definitions: 

a) reception of layer 3 information in the synchronization broadcast and system information broadcast. The 
broadcast shall be recognized by layer 2 and forwarded to layer 3 as SDU elements inside primitives: 

TL-SYNC indication; 

TL-SYSINFO indication; 

TL-SYSINFO-Q indication. 

1 8.2.7 Services and primitives between tine MLE and tine LLME 

The LLME may be used for exchanging layer-to-layer information. In the protocol stack (see figure 18.1) the access to 
the LLME is modelled in the TLC-SAP. 

The following primitives should be defined for this SAP: 

a) control of scanning (MS side only): 

TL-SCAN request/confirm; 
TL-SCAN-REPORT indication. 

b) selecting cell for attachment (MS side only): 

TL-SELECT request/indication/confirm. 

c) control of neighbour cell monitoring and channel monitoring (MS side only): 

TL-MONITOR-LIST request; 
TL-MONITOR indication. 

d) control of channel assessment (MS side only): 

TL-ASSESSMENT-LIST request; 
TL-ASSESSMENT indication. 

e) receive quality information on the serving cell and current channel (MS side only): 

TL-MEASUREMENT indication. 

f) receive path loss information (MS side only): 

TL-REPORT indication. 

g) set up and configure layer 2 according to commands from service SAP users (MS side only): 

TL-CONFIGURE request/confirm, 
h) layer 2 configuration information to service SAP users (MS side only): 
TL-CONFIGURE indication. 
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18.2.8 Protocol sequences 



The basic protocol primitive sequences are shown in figures 18.2 to 18.4. The operation of the protocol should be 
modelled as a finite state automaton governed by a state variable. A transition of the automaton should be prompted by 
the occurrence of an event at one of three interfaces: 

a) the interface to any of the service users (MM, CMCE, SNDCP); 

b) the interface to the underlying service which is the V+D layer 2; 

c) the interface to the LLME. 



Break and resume 
communication on a lUILE 
connection 

MLE-BREAK indication 



MLE-RESUME indication 
< 



Opening or closing 
of networit access 



MLE-OPEN indication 
MLE-GLOSE indication 
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Setup of advanced Linl< or 
Reset of advanced linl< 
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MLE-CONNECT confirm 
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MLE-RESUME indication 
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MLE-CONNECT response 
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Figure 18.2: Primitive time sequence at tfie LTPD-SAP 
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LMM mobile SAP 



Initialisation, re-initialisation 
and activation of MLE 

MLE-ACTIVATE indication 
< 



MLE-ACTIVATE request 



MLE-ACTIVATE confirm 



Deactivation of MLE 



MLE-DEACTIVATE request 



Open or close network access 



MLE-OPEN request 



MLE-CLOSE request 



Registration, Intervention 
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Data transfer 
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LMM SwMI SAP 
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Figure 18.3: Primitive time sequence at the LMM-SAP 
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LCMC mobile SAPs 



LCMC SwMI SAPs 
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Restore a circuit mode call 

MLE-RESTORE r equest 



MLE-RESTORE contirm 



)njii 



MLE-RESTORE indication 
> 



MLE-RESTORE response 



Figure 18.4: Primitive time seguence at the LCMC-SAP 
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18.3 MLE functions 



18.3.1 Overview 

The MLE functional groups are shown in figure 18.5. 



SNDCP 



CMCE 



LTPD-SAP 



MLE 



MM 



LCMC-SAP 



LMM-SAP 



Network 
Broadcast 



Data Transfer 



TLA-SAP 



Attachment 
Management 



Management 
Entity (TMI) 



TLB-SAP 



TLC-SAP 



Layer 2 

Figure 18.5: MLE functional model 

The MLE functional entities are: 

a) attachment management: 

management of monitoring and scanning procedures; 

surveillance of the serving cell quality; 

management of the ranking procedure; 

management of the cell relinquishable, improvable and usable radio criteria; 

management of the channel relinquishable, improvable and usable radio criteria; 

management of the roaming announcements and declarations; 

informing upper entities CMCE and SNDCP of broken and restored MLE connections via the data 
transfer sub-entity; 

informing the SwMI about usable sectored channels and channel classes. 
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b) data transfer: 

selection of underlying LLC service; 

address handling (ISSI, GSSI and TMI); 

informing the upper entities CMCE and SNDCP of enabled and disabled access to the communication 
resources; 

routing and multiplexing to layer 2 service end points and links (including addition/removal of MLE 
protocol control information); 

routing and multiplexing to MLE SAPs and other MLE functional entities; 

quality of service mapping (e.g. PDU priority, data priority, throughput, delay, reliability, data class, 
scheduled access and transfer service). 

c) network broadcast: 

formatting and broadcasting of the network information (SwMI); 

reception and analysis of network information (MS/LS); 

configuring of MAC layer 2 with synchronization and system information broadcast. 

d) management: 

handling network management procedures, e.g. addressed to the TETRA Management Identity (TMI); 
handling local management information from the management entity to the lower layers. 

1 8.3.2 Access to the communication resources and activation of tine MLE 

Access to all communication resources is controlled by the MLE, according to requests received from the MM entity. 

At power on, or other start-up, there is no requirement that the MLE shall have any prior knowledge of the suitability of 
any cell. In order that the MS can communicate, the MLE shall select a suitable cell. A suitable cell should be one in 
which the MS can reliably decode downlink data, which has a high probability of uplink communication and that the 
MS may request and obtain service. 

The procedures defined in the following clauses describe methods by which the MS can select a cell. 

The MLE cell selection procedure is initiated by the MM entity defining the cell selection criteria (e.g. mobile network 
identity) in an MLE-ACTIVATE request primitive. When a suitable cell has been found the MLE issues an 
MLE-ACTIVATE confirm primitive to the MM to report the cell details. Initially the radio communications link may 
only be used for MM data transfer until the MM issues an MLE-OPEN request primitive thereby instructing the MLE to 
open access to the layer 3 entities. The MM entity issues the MLE-OPEN request primitive after completion of any MM 
procedures (e.g. registration). An MLE-OPEN request primitive is received by both the attachment management and the 
data transfer sub-entities within the MLE. The opening of link access is reported to the CMCE and SNDCP with an 
MLE-OPEN indication primitive. 

NOTE: If no MM procedures are required, the MM may issue the MLE-OPEN request primitive immediately 
after the MLE-ACTIVATE confirm primitive is received. 

The MLE on the MS side can take the decision to change cell from measurement processing and threshold comparisons. 
MM shall be informed with an MLE-LINK indication primitive in the event that the cell reselection results in the 
selection of a cell in a LA that is not in the current registration area. The parameters associated with the MLE-LINK 
indication primitive inform the MM of the LA, MNC and MCC of the new cell. 

1 8.3.3 Deactivation of tine MLE 

Upon receipt of an MLE-DEACTIVATE request primitive the MLE shall cease all functions. The 
MLE-DEACTIVATE request primitive should be preceded by an MLE-CLOSE request primitive to the data transfer 
sub-entity. 
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18.3.4 Attachment management sub-entity 



The attachment management sub-entity shall be responsible for the initial cell selection and cell reselection procedures. 
The initial cell selection and cell reselection procedures comprise the functions listed below. These following functions 
shall be activated at power on: 

management of the monitoring and scanning procedures; 

surveillance of the serving cell quaUty; 

management of the neighbour cell ranking procedure; 

management of the cell reselection criteria; 

management of the cell reselection announcements and declarations; 

informing upper entities CMCE and SNDCP of broken and restored MLE connections via the data transfer 
sub -entity. 

Cell selection and reselection shall only be carried out using the individual or alias subscriber identities. Cell reselection 
shall not be carried out using group addresses. Any cell reselection messages received on a GSSI shall be ignored. 

Where the MS is engaged in more than one call, the MS shall only apply the cell reselection procedures once and not 
for each call in progress. Once a cell has been re-selected the CMCE may restore the calls. 

18.3.4.1 Scanning of cells 

Scanning is where an MS is synchronized to a cell, directly measures the received power of that cell and directly obtains 
the broadcast and synchronization information for that cell by decoding the BNCH and BSCH. The scanning 
sub-function enables the MLE to directly obtain the path loss measurements from the cells. To obtain the CI path loss 
parameter from layer 2, the MS-MLE shall per cell issue a TL-SCAN request primitive to the TLC-SAP along with the 
parameters indicating which cell is to be scanned. 

The MS-MLE shall know locally which channels the MS is capable of scanning and shall not instruct the lower layers 
to scan any channel that the MS-MLE knows to be outside the capabilities of the equipment. When layer 2 has 
completed scanning of one cell, the CI path loss shall be part of the report parameter of the TL-SCAN confirm 
primitive or of the TL-SCAN-REPORT indication primitive, both given by layer 2. The CI formula is defined in 
clause 23. The MS-MLE can use the list of neighbour cells in the D-NWRK-BROADCAST PDU to specify which 
channels to be scanned. 

There are three types of scanning defined in clause 23. These are: 

• foreground, where scanning is the only activity; 

• background, where communications with the current serving cell are maintained in parallel with the scanning, 
and the scanning causes no interruption to that service; 

• interrupting, where communications with the current serving cell are maintained in parallel with the scanning, 
but the scanning causes limited interruptions to that service. 

Scanning shall have been performed within the last 60 s for a scanning measurement to be considered valid. 

1 8.3.4.2 Monitoring of neighbour cells 

Neighbour cell monitoring is where the MS calculates the path loss parameter C2 of neighbour cells using information 
about the neighbour cells broadcast by the serving cell. It differs from CI in that the serving cell provides the cell 
selection parameters for the neighbour cell. However, the MS is still required to directly measure the received power of 
the neighbour cell. 
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In order to be able to monitor the neighbour cells the MS-MLE shall have received a D-NWRK-BROADCAST PDU 
containing a list of the neighbour cells. The procedures concerning network broadcast PDUs are dealt with in 
clause 18.3.6. Once the network broadcast information has been received, the monitoring can be started by issuing a 
TL-MONITOR-LIST request primitive through the TLC-SAP. The TL-MONITOR-LIST request primitive informs 
layer 2 of the cells to be monitored. The parameters passed down with the TL-MONITOR-LIST request primitive shall 
be a list of channels corresponding to phase modulation carriers. The MS-MLE shall know locally which channels the 
MS is capable of monitoring and shall not instruct the lower layers to monitor any channel that the MS-MLE knows to 
be outside the capabilities of the equipment. For each channel the lower layers return a TL-MONITOR indication 
primitive containing the C2 path loss parameter. C2 is defined in clause 23. 

Neighbour cell monitoring is a background procedure and is defined in clause 23. Monitoring of neighbour cells shall 
have been performed during the last 60 s for a monitoring measurement to be considered valid. 

If it is required to stop the neighbour cell monitoring process, the MLE shall issue a TL-MONITOR-LIST request 
primitive with an empty list of neighbour cell channels as parameter. 

1 8.3.4.3 Surveillance of the serving cell 

Serving cell surveillance is the procedure whereby the MS analyses the received information on the quality of the link 
to the serving cell's main carrier. Once the MS-MLE has chosen the serving cell, the MLE shall select that cell by 
issuing a TL-SELECT request primitive to the TLC-SAP. Once the cell has been selected the lower layers return a 
TL-SELECT confirm primitive and periodically send TL-MEASUREMENT indication primitives containing the CI 
path loss parameter for the current channel. If the current channel is a non-conforming channel (see clause 18.3.4.9.1), 
the lower layers include the C3 path loss parameter for the main carrier in the TL-MEASUREMENT indication 
primitive. 

If the current channel is a conforming channel (clause 18.3.4.9.1), the MS-MLE shall assess the quality of the link to the 
serving cell's main carrier using the CI path loss parameter for the conforming channel or channels. 

If the current channel is a non-conforming concentric channel or a sectored channel (indicated in the channel 
information parameter of the TL-SELECT indication primitive), the MS-MLE shall assess the quality of the link to the 
serving cell's main carrier using either the C3 path loss parameter or the C2 path loss parameter. The MS-MLE may 
obtain the C2 path loss parameter by requesting layer 2 to monitor the serving cell's main carrier using the 
TL-MONITOR-LIST request primitive. When the MS-MLE receives the C2 path loss parameter for the main carrier, it 
shall use C2 in preference to C3 for determining the quality of the link to the serving cell. (Whereas C2 gives a direct 
measurement of the main carrier's performance, C3 predicts the main carrier performance from measurements made on 
the current channel.) 

NOTE 1 : On a sectored channel, the C2 path loss parameter is more reliable than the C3 path loss parameter. For 
example, C3 may be lower than C2 (i.e. the C3 path loss may be overestimated) when the MS is near the 
azimuthal boundary of a sectored channel. If the MS-MLE relies on the C3 path loss parameter near an 
azimuthal boundary, the MS-MLE might decide to perform a cell reselection at a time when a sector 
change would be more appropriate. To take account of this, the MS-MLE could request C2 measurements 
(i.e. monitoring of the serving cell's main carrier) when the C3 path loss parameter suggests that the main 
carrier may be failing. When the MS is monitoring the main carrier, the MS-MLE could use comparisons 
between the C2 and C3 path loss parameters to decide if the MS can cease monitoring the main carrier. 

NOTE 2: The MS may choose to monitor the serving cell's main carrier when using a non-conforming concentric 
channel. 

The CI, C2 and C3 path loss parameters are described in clause 23. Additionally the surveillance sub-function shall be 
responsible for the analysis of any network broadcast information received from the serving cell via the network 
broadcast sub-entity. 

If a serving cell radio link failure occurs (see clause 18.3.4.5.3), the MLE shall inform the upper entities SNDCP and 
CMCE by issuing an MLE-BREAK indication primitive via the data transfer sub-entity. 

If a current channel radio link failure occurs (see clause 18.3.4.5.3), the MLE shall send layer 2 a TL-SELECT request 
primitive requesting selection of the main control channel. The MLE data transfer sub-entity shall send 
an MLE-CONFIGURE indication primitive containing "loss of radio resource" to the service user(s) who is using this 
radio resource as indicated by the endpoint identifier parameter. 
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Should the MLE receive a TL-REPORT indication primitive from the lower layers indicating "usage marker failure" 
then a TLC-CONFIGURE request primitive shall be generated to move the MS to the control channel and the upper 
entities CMCE and SNDCP shall be informed via a MLE-CONFIGURE indication primitive containing "loss of radio 
resource". 

If the MLE receives a TL-SELECT indication primitive via the TLC-S AP, outside of cell reselection, indicating that the 
MAC has been instructed to change channels and no response is required, the surveillance function shall note the new 
serving cell channel. 

If the MS is using concurrent channels, layer 2 may send the MS-MLE a CI path loss parameter for each separate 
channel. If none of the concurrent channels are conforming channels, layer 2 shall send the MS-MLE one or more C3 
values for the main carrier. The MS-MLE should combine multiple C3 values for the purposes of assessing the 
performance of the main carrier. The method of combining multiple C3 values is outside the scope of the present 
document. 

1 8.3.4.4 Ranking of neighbour cells 

The ranking sub-function can use the path loss measurements CI and C2 to maintain a ranked list of neighbour cells. 

The ranking algorithm shall rank the neighbour cells which have been monitored or scanned in strict order of downlink 
radio connection quality. The results of this algorithm can be used to determine when a cell is deemed to be radio 
usable, radio relinquishable or radio improvable according to clause 18.3.4.7. The use of a ranking algorithm based only 
on CI or C2 is essential in order to facilitate network coverage planning. 

A cell shall meet the following minimum criteria in order to be included in the ranking list of neighbour cells: 

• CI > or C2 > 0; 

NOTE: The current registration area consists of all of the LAs in which the MS is currently registered. 

• if the neighbour cell has a different MCC or MNC, the neighbour cell shall support migration (which is 
broadcast as part of the BS service details element). 

If these criteria are not satisfied, an MS shall not include that cell in the ranking list and so shall not consider that cell 
for cell reselection. 

If the information about the LA or MCC or MNC is not broadcast by the serving cell as part of the neighbour cell 
information, the MS may assume that is it is free to include that cell in its ranking list provided the CI > or C2 > 
criterion is met. 

An MS can build a valid ranking list by obtaining the cell reselection parameters for the neighbour cells from the 
D-NWRK-BROADCAST PDU transmitted on the serving cell. In this case, the MS shall monitor the neighbour cells 
specified by the D-NWRK-BROADCAST PDUand shall calculate C2 for each one using the cell reselection parameters 
for the neighbour cell sent in the D-NWRK-BROADCAST PDU on the serving cell. A valid ranking list can then be 
derived using the C2 measurements. 

An MS can also build a valid ranking list by scanning the neighbour cells to obtain the cell reselection parameters 
directly. In this case, the MS shall calculate CI for each of the neighbour cells and shall derive a valid ranking list using 
the CI measurements. 

18.3.4.4.1 Ranking of monitored cells 

Ranking of monitored neighbour cells shall be based upon the received path loss parameter C2 from the layer 2 
monitoring process, issued in a TL-MONITOR indication primitive. 

The ranking should produce a ranked cell list which can be used as a scanning list, if the scanning function is applied. 
This ranked cell list may be used for making the decision of whether and when to change cell, according to 
clause 18.3.4.7. 



£75/ 



421 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 



1 8.3.4.4.2 Ranking of scanned cells 



Ranking of scanned neighbour cells shall be based upon the received path loss parameter CI from the layer 2 scanning 
process, issued in a TL-SCAN confirm primitive or a TL-SCAN-REPORT indication primitive. 

The ranking should produce a ranked cell list which may be used for making the decision of whether and when to 
change cell, according to clause 18.3.4.7. 

1 8.3.4.5 Criteria used during cell reselection 

The following clauses define the criteria which shall be used to initiate the cell reselection procedures described in 
clause 18.3.4.6. 

1 8.3.4.5.1 Criterion for starting the neighbour cell monitoring process 

The neighbour cell monitoring process may be permanently enabled or enabled only when some criterion is met, 
e.g. the serving cell ceases to support the service level required by the MS, or the serving cell quality falls below a 
pre-determined threshold. In the latter case it is assumed that the neighbour cell monitoring process would be disabled 
when the serving cell quality rises above the threshold plus some hysteresis factor. 

The exact method for the selection of the thresholds and hysteresis values is outside the scope of the present document. 

Where the neighbour cell monitoring process is not permanently enabled and the MS-MLE receives system broadcast 
information informing it that the service level required by that MS is no longer supported, e.g. that the subscriber class 
that the MS belongs to is no longer able to access the system, the neighbour cell monitoring process should be started. 

Where the neighbour cell monitoring process is not permanently enabled, but started when a threshold value is crossed, 
the threshold value should be chosen to be a value greater than the threshold parameters, 

FAST_RESELECT_THRESHOLD, SLOW_RESELECT_THRESHOLD, to allow the MS enough time to successfully 
select a new cell prior to the complete loss of service from the current serving cell. 

If the ranking list contains cells that recommend expedited cell reselection in the "Cell reselection types supported" 
information element and at least one neighbour cell recommends expedited cell reselection then the MS should use a 
higher threshold for starting to monitor its neighbour cells or the MS may monitor the neighbour cells continuously. 

1 8.3.4.5.2 Criterion for starting scanning 

The individual criteria for starting scanning in the different selection and reselection procedures are defined in 
clauses 18.3.4.6 and 18.3.4.7.1 to 18.3.4.7.6. 

1 8.3.4.5.3 Criterion for radio link failure 

Radio link failure occurs when the quality of the uplink or downlink radio connection falls below a certain level. A 
radio link failure shall be declared if any of the following events occur: 

• layer 2 declares CI path loss parameter failure (CI < 0) via the TL-MEASUREMENT indication primitive: 

if the current channel is a non-conforming channel (see clause 18.3.4.9.1) this shall be considered a 
current channel radio link failure; or 

if the current channel is a conforming channel (see clause 18.3.4.9.1) this shall be considered a serving 
cell radio link failure; 

• layer 2 reports path loss parameter C3 < for the serving cell's main carrier via the TL-MEASUREMENT 
indication primitive: 

this shall be considered a serving cell radio link failure unless the MS-MLE immediately initiates or has 
already initiated monitoring of the main carrier; 

• layer 2 reports path loss parameter C2 < for the serving cell's main carrier via the TL-MONITOR indication 
primitive: 

this shall be considered a serving cell radio link failure; 
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• layer 2 reports an AACH or AACH-Q decoding failure as described in clause 23 for a current channel via the 
TL-REPORT indication primitive (downlink failure); then: 

if the current channel is a non-conforming channel (see clause 18.3.4.9.1) this shall be considered a 
current channel radio link failure; or 

if the current channel is a conforming 7t/4-DQPSK or D8PSK channel this shall be considered a serving 
cell radio link failure; 

if the current channel is a conforming QAM channel this shall be considered a current channel radio link 
failure; 

• an error is reported via the TL-REPORT indication primitive indicating either: 

that the maximum path delay has been exceeded - this shall be considered a serving cell radio link 
failure; or 

that an uplink failure has occurred; then: 

■ if the channel on which the uplink failure occurred is a non-conforming channel this shall be 
considered a current channel radio link failure; or 

■ if the channel on which the uplink failure occurred is a conforming channel this shall be considered 
a serving cell radio link failure. 

• layer 2 declares that the BS has entered no service mode for the serving cell via the TL-REPORT indication 
primitive (common channel deallocated). 

NOTE: The maximum path delay exceeded condition and the uplink failure condition can be reported to the MS 
MAC from the SwMI in a MAC RESOURCE PDU. 

1 8.3.4.5.4 Criterion for radio relinquishable cell 

A serving cell becomes radio relinquishable when the quality of the serving cell's main carrier downlink radio 
connection falls below a certain level and there is a neighbour cell which has a downlink radio connection of sufficient 
quality. 

The following conditions shall be met simultaneously in order to declare the serving cell radio relinquishable: 

• the serving cell main carrier path loss parameter CI or C3 shall for a period of 5s fall below 
FAST_RESELECT_THRESHOLD; 

• the main carrier path loss parameter, CI or C2, of at least one of the neighbour cells in the ranking list shall 
exceed by FAST_RESELECT_HYSTERESIS the path loss parameter, CI, C2 or C3 of the current serving 
cell's main carrier for a period of 5 s (where C2, if available, takes precedence over C3); 

• no successful cell reselection shall have taken place within the previous 15 s unless MM requests a cell 
reselection. 

The MS-MLE shall check the criterion for serving cell relinquishment as often as one neighbour cell is scanned or 
monitored. 

1 8.3.4.5.5 Criterion for radio improvable cell 

A serving cell becomes radio improvable when the quality of a neighbour cell downlink radio connection exceeds that 
of the serving cell by a certain amount. The following conditions shall be met simultaneously in order to declare the 
serving cell radio improvable: 

• the serving cell main carrier path loss parameter CI, C2 or C3 shall, for a period of 5 s, fall below 
SLOW_RESELECT_THRESHOLD (where C2, if available, takes precedence over C3); 

• the main carrier path loss parameter, CI or C2, of at least one of the neighbour cells in the ranking list shall 
exceed by SLOW_RESELECT_HYSTERESIS the main carrier path loss parameter CI, C2 or C3 of the 
current serving cell for a period of 5 s (where C2, if available, takes precedence over C3); 
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• no successful cell reselection shall have taken place within the previous 15 s unless MM requests a cell 
reselection. 

The MS-MLE shall check the criterion for improving the serving cell as often as one neighbour cell is scanned or 
monitored. 

1 8.3.4.5.6 Criterion for radio usable cell 

A neighbour cell becomes radio usable when it has a downlink main carrier radio connection of sufficient quality. The 
following condition shall be met in order to declare a neighbour cell radio usable: 

• the neighbour cell shall for a period of 5s have a main carrier path loss parameter, CI or C2, which is greater 
than (FAST_RESELECT_THRESHOLD + FAST_RESELECT_HYSTERESIS); 

• no successful cell reselection shall have taken place within the previous 15 s unless MM requests a cell 
reselection. 

The MS-MLE shall check the criterion for a neighbour cell being usable each time the neighbour cell is scanned or 
monitored. 

1 8.3.4.5.6b Criterion for expedited cell reselection 

A neighbour cell becomes candidate for expedited cell reselection when the following conditions are met 
simultaneously: 

• the path loss parameter, CI or C2, of at least one of the neighbour cells in the ranking list shall exceed by 
FAST_RESELECT_HYSTERESIS the path loss parameter, CI, of the current serving cell for a period of 2 s; 

• the neighbour cell in question is indicated to recommend expedited cell reselection (in the "cell reselection 
types supported" information element of the D-NWRK-BROADCAST PDU); and 

• no successful cell reselection shall have taken place within the previous 15 s unless MM requests a cell 
reselection. 

NOTE 1 : In order to successfully perform an expedited cell reselection the MS implementation should consider the 
following aspects: 

■ The required time for a cell reselection criterion to be in effect should be reduced from 5 s to 2 s. 

■ The neighbour cell monitoring should be performed at the fastest available rate. 

■ If the MS attempts announced cell reselection the waiting time for D-NEW CELL, T370, should be 
shortened to 3 s. 

■ Reduce the filtering of RSSI and C1/C2 measurements. 

NOTE 2: Where encryption is used, either DCK forwarding should be used with a reduced T370 timer of 3 s or 
DCK retrieval should be used to avoid clear location update on the new cell. 

1 8.3.4.5.7 Criteria for initiating the cell reselection procedures 

Cell reselection shall be initiated by the MLE if the serving cell is declared radio improvable (as defined in 

clause 18.3.4.5.5) and the service criteria as defined below are the same on both the serving cell and the radio 

improvable neighbour cell. If the service provided by the neighbour cell is lower than that provided by the serving cell, 

the cell reselection may be postponed until the serving cell is declared radio relinquishable (as defined in 

clause 18.3.4.5.4). If the service provided by the neighbour cell is higher than that provided by the serving cell, then the 

cell reselection may be performed as soon as the neighbour cell is declared radio usable (as defined in 

clause 18.3.4.5.6). 
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If cell reselection is initiated by the user application, the MLE shall receive a MLE-LINK request primitive from MM 
containing the MCC and MNC and possibly also the LA of the desired cell. If, within the LA(s) specified in the 
MLE-LINK primitive request, the MLE is able to find a cell fulfilling the criterion where service provided by the 
neighbour cell is same or higher than provided by the serving cell, then the cell reselection may be performed as soon as 
the neighbour cell is declared radio usable (as defined in clause 18.3.4.5.6). Upon selection of the new cell, the MLE 
shall send a MLE-LINK indication primitive to MM. If the MLE is unable to find a suitable cell, it shall respond to MM 
with a MLE- ACTIVATE indication primitive. 

The following service criteria may be used to compare the service provided by a serving cell and a neighbour cell: 

support for subscriber class (broadcast as part of D-MLE-S YSINFO and D-MLE-SYSINFO-Q PDUs); 

support for system-wide services (broadcast as part of the BS service details element); 

priority cell indication (broadcast as part of the BS service details element); 

support for TETRA standard speech (broadcast as part of the BS service details element); 

support for TETRA circuit mode data (broadcast as part of the BS service details element); 

support for TETRA packet data services (broadcast as part of the BS service details element); 

support for air interface encryption (broadcast as part of the BS service details element); 

cell service level (broadcast as part of D-MLE-SYNC and D-MLE-SYSINFO-Q PDU); 

whether or not the current serving cell or LA is preferred over the neighbour cell (which be may stored in the 
MS at subscription); 

whether or not a circuit mode call or C-plane signalling transfer is in progress; 

support for the QAM modulation mode (broadcast as part of the extended services broadcast element); 

support for the D8PSK modulation mode (broadcast as part of the extended services broadcast element); 

the bandwidths supported (broadcast as part of the extended services broadcast element); 

support for QoS negotiation during PDF context activation (broadcast as part of extended services broadcast 
element); 

a recognized system code (see clause 21.4.4.2). 

The MS shall not use an unrecognized system code (i.e. a value defined as reserved according to all system codes 
known by the MS) in the V H- D range to identify the service provided by a cell. The MS shall not reject the cell based 
only on an unrecognized system code in the Vh-D range. 

NOTE: The system code is a shorthand indication for what the system is supporting or more accurately what the 
system is not supporting. The system code may vary between cells belonging to the same system. 

The BS service details element for the serving cell is broadcast in the D-MLE-SYSINFO PDU (transmitted on BNCH) 
and the D-MLE-SYSINFO-Q PDU (transmitted on BNCH-Q). The cell service level element for the serving cell is 
broadcast in the D-MLE-SYNC PDU (transmitted on BSCH) and the D-MLE-SYSINFO-Q PDU. The extended 
services broadcast element is broadcast in the MAC SYSINFO PDU and the MAC SYSINFO-Q PDU. The 
BS service details elements and the cell service level elements for neighbour cells are broadcast in the 
D-NWRK-BROADCAST PDU. 

BSCH and BNCH shall be transmitted on the serving cell and the D-NWRK-BROADCAST PDU may be transmitted 
on the serving cell. BNCH-Q may be transmitted on the serving cell. 

Using the above criteria, an MS may decide whether or not a neighbour cell can be considered to offer better service 
than the current serving cell. The following conditions shall cause the MS to rate a neighbour cell to have better service 
than the current serving cell: 

• the MS subscriber class is supported on the neighbour cell but not on the serving cell; 

• the neighbour cell is a priority cell and the serving cell is not a priority cell; 
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• the neighbour cell supports a service (i.e. TETRA standard speech, circuit mode data or TETRA packet data 
services) which is not supported by the serving cell and the MS requires that service to be available; 

• the neighbour cell supports a modulation mode (e.g. D8PSK, QAM) which is not supported by the serving cell 
and the MS requires that service to be available; 

• the neighbour cell supports a higher bandwidth matching the MS's capabilities than does the neighbour cell, 
and the the MS requires the ability to use that higher bandwidth; 

• the neighbour cell supports QoS negotiation during PDF context activation and the serving cell does not, and 
the MS requires the use of services accessed via QoS negotiation (e.g. D8PSK and QAM channels, scheduled 

access); 

• the neighbour cell supports air interface encryption which is not supported by the serving cell and the MS 
requires that air interface encryption is available; 

• the neighbour cell supports system-wide services which are not supported by the serving cell; 

• the cell service level indicates that the neighbour cell is more lightly loaded than the serving cell; 

• the neighbour cell is a preferred cell (or "home cell") or belongs to a preferred LA. 

In these cases the MS may choose to initiate cell reselection as soon as the neighbour cell becomes radio usable as 
defined in clause 18.3.4.5.6. If there is more than one neighbour cell which is radio usable, the MS should choose the 
one which gives has the highest ranking in the ranking list and which best satisfies the service requirements for the MS. 

If the service provided by a radio usable neighbour cell is higher than that provided by the serving cell, but an assigned 
channel on the serving cell provides a better service than any neighbour cell channel that is currently radio usable, the 
MS-MLE may postpone cell reselection (the MS-MLE discovers this by monitoring the neighbour cell sectored 
channels and assessing the quality of the neighbour cell channel classes - see clauses 18.3.4.9.4 to 18.3.4.9.8). 

The following conditions shall cause the MS to rate a neighbour cell to have lower service than the current serving cell: 

• the MS subscriber class is not supported on the neighbour cell but is supported on the serving cell; 

• the serving cell is a priority cell and the neighbour cell is not a priority cell; 

• the serving cell supports a service (i.e. TETRA standard speech, circuit mode data or TETRA packet data 
services) which is not supported by the neighbour cell and the MS requires that service to be available; 

• the serving cell supports a modulation mode (e.g. D8PSK, QAM) which is not supported by the neighbour cell 
and the MS requires that service to be available; 

• the serving cell supports a higher bandwidth matching the MS's capabilities than does the neighbour cell, and 
the the MS requires the ability to use that higher bandwidth; 

• the serving cell supports QoS negotiation during PDP context activation and the neighbour cell does not, and 
the MS requires the use of services accessed via QoS negotiation (e.g. D8PSK and QAM channels, scheduled 

access); 

• the serving cell supports air interface encryption which is not supported by the neighbour cell and the MS 
requires that air interface encryption is available; 

• the serving cell supports system-wide services which are not supported by the neighbour cell; 

• the cell service level indicates that the serving cell is loaded more lightly than the neighbour cell; 

• the serving cell is a preferred cell (or "home cell") or belongs to a preferred LA. 

In these cases the MS may postpone cell reselection until the serving cell becomes radio relinquishable as defined in 
clause 18.3.4.5.4. If there is more than one neighbour cell which causes the serving cell to be radio relinquishable, the 
MS should choose the highest ranked cell in the ranking list which satisfies the service requirements for the MS. 



£75/ 



426 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

If the service provided by a radio usable neighbour cell is lower than that provided by the serving cell, but the 
neighbour cell is advertising a radio usable sectored channel or a radio usable channel class which offers a higher 
service than is available on a currently assigned channel (the MS-MLE discovers this by monitoring the neighbour cell 
sectored channels and assessing the neighbour cell channel classes - see clauses 18.3.4.9.4 to 18.3.4.9.8), the MS-MLE 
may initiate cell reselection immediately if more than 15 s has elapsed since a previous cell reselection. 

If the neighbour cell is deemed to offer neither better service or lower service over the serving cell, the service shall be 
deemed to equal and the MS shall initiate the cell reselection procedures as soon as a neighbour cell becomes radio 
improvable over the current serving cell as defined in clause 18.3.4.5.5. A neighbour cell shall be deemed to be equal 
with respect to the above service criteria if the information is not available for either the serving or neighbour cell 
e.g. the cell service level may not be included in the D-NWRK-BROADCAST PDU causing the service to be deemed 
equal with respect to cell service level. 

If a neighbour cell is deemed to provide equal or better service than the current serving cell and the neighbour does not 
recommend expedited cell reselection, the cell reselection should be postponed if there is a circuit mode call or ongoing 
signalling currently in progress. In this case, the cell reselection should be postponed until the serving cell becomes 
radio relinquishable, even if there are neighbour cells which meet the radio improvable or radio usable criteria. 

If serving cell radio link failure occurs (which can occur when there are no neighbour cells of sufficient radio 
connection quality to make the serving cell relinquishable), the MS may re-select any neighbour cell in the ranking list 
whose main carrier path loss parameter, CI or C2, is greater than zero. If there are multiple cells in the ranking list 
which meet this radio criterion, the MS should choose the highest ranked cell which satisfies the service requirement for 
the MS. If there are no cells which meet this minimum radio criterion, the initial cell selection procedure shall be 
invoked. 

18.3.4.6 Initial cell selection 

The MS shall implement the initial cell selection procedure when the MS-MLE receives an MLE- ACTIVATE request 
primitive from MM e.g. when not attached to a cell, at power on, or after a previous deactivation has taken place. The 
exact detailed implementation of the procedure and any associated algorithms is outside the scope of the present 
document. The MS shall be required to fulfil certain conditions as stated below. The procedure shall be referred to as 
the "initial cell selection" procedure. This does not imply that the procedure shall necessarily be different from any 
procedures applied for cell reselection. 

The initial cell selection procedure shall ensure that the MS selects a cell in which it can reliably decode downlink data, 
i.e. on a main control channel (MCCH), and which has a high probability of uplink communication. The minimum 
conditions that shall have to be met are that CI > 0. Access to the network shall be conditional on the successful 
selection of a cell. 

The procedure shall be initiated by the receipt of the MLE-ACTIVATE request primitive from the MM entity. This 
primitive has parameters which include the MCC and the MNC of the particular network which the MS should select. 
The MS-MLE shall then use this information, and initiate the foreground scanning procedure and thus obtain the path 
loss parameter CI and the network broadcast information for each cell. This information can be used to produce a list of 
preferred cells. These cells shall then be ranked by the MS-MLE. The ranking algorithm is outside the scope of the 
present document. 

In the event that there are no suitable cells available when all cells in the list have been scanned, the MLE shall inform 
the MM entity with an MLE-ACTIVATE indication primitive that no suitable cell has been found. The MLE shall 
continue the scanning of cells until a suitable cell is found, or until the MS is powered down. The exact procedures, 
algorithms and parameters applied for the continued scanning of cells are outside the scope of the present document. 

The MS shall select a cell which has CI > 0. The MS should choose the cell which has the highest ranking according to 
the initial cell selection ranking procedure. 

NOTE: The initial cell selection ranking procedure is not defined by the present document. 

The cell shall be selected by issuing a TL-SELECT request primitive to the TLC-SAP. The parameters of the 
TL-SELECT request primitive inform the lower layers of the channel and the parameters, MS_TXPWR_MAX_CELL 
and RXLEV_ACCESS_MIN for the cell. Once the cell has been selected the lower layers return a TL-SELECT confirm 
primitive. The MLE shall issue an MLE-ACTIVATE confirm primitive to the MM. If registration is required in the cell, 
the MM shall then register. If the registration is successful or if no registration is required, the MLE may receive an 
MLE-UPDATE request primitive from MM supplying information regarding updated search areas for further 
monitoring. 
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If the registration is to a cell which has its "System wide services" parameter set to "System wide services temporarily 
not supported" and the registration is accepted with a Location update accept type value of "Temporary registration" 
then the MS shall consider itself to be temporarily registered. 

If the MS has received a "Temporary registration" acknowledgement and then initiates a cell reselection, it shall register 
to the new cell even if the cell belongs to the Registered Area of the MS. 

In the event that the initial cell selection is unsuccessful as a result of registration or authentication failure, MM shall 
instruct the MLE attachment management sub-entity, using an MLE-UPDATE request primitive, to suspend the ranking 
of that cell. This shall result in the selection of a different cell by the MLE, unless all opportunities have been used, in 
which case MM shall close the MLE service. 

Upon receipt of the MLE-OPEN request primitive, the MLE shall send MLE-OPEN indication primitive to the higher 
layer 3 entities, CMCE and SNDCP and shall initiate the serving cell surveillance procedures for the new cell as defined 
in clause 18.3.4.3 and may also initiate monitoring or background/interrupting scanning of neighbour cells. 

18.3.4.7 Cell reselection 

1 8.3.4.7.0 Overview of cell reselection 

This clause defines the overall process of the cell reselection procedure. 

The cell reselection procedure shall ensure that the MS selects a cell in which it can reliably decode downlink data, i.e. 
on a main control channel, and in which it has a high probability of uplink communication according to the criteria in 
clause 18.3.4.5.7. The minimum conditions which shall have to be met are that CI > and that the maximum path delay 
is not exceeded. 

NOTE: The SwMI informs the MS that maximum path delay is exceeded in a MAC-RESOURCE PDU. 

If the cell reselection procedure is unsuccessful, such that the MLE is left with no usable radio channels, the MS-MLE 
shall indicate this to the MM using an MLE-ACTIVATE indication primitive. MM may give further instructions, 
e.g. new LAs, or, if all opportunities have been used, MM shall close the MLE services (see clause 16). When the MM 
eventually opens up the services again, MS-MLE shall be activated and the initial cell selection procedures as specified 
in clause 18.3.4.5 shall apply. 

Cell reselection can be performed by the MS-MLE when a MS is attached to a cell in idle or traffic mode. The 
procedure can handle the following categories as listed below: 

undeclared; 

unannounced; 

announced type 3; 

announced type 2; 

announced type 1 . 

Where an MS is not involved in any voice or circuit mode data calls, then the MS-MLE shall perform undeclared cell 
reselection. Where a MS is involved in a voice or circuit mode data call, then cell reselection shall be performed based 
on the criteria set out below and in figure 18.6. In the cases, where there is an advanced link established and where the 
MS does not support advanced link roaming, it is recommended that the MS-MLE disconnects this advanced link prior 
to performing cell reselection. 

Undeclared cell reselection is performed by the MLE when there are no calls in progress. The MS may attempt to 
recover SNDCP and/or advanced link connections on the new cell. 

Unannounced cell reselection is used when the MS is unable to or, in the case of listening to group calls, has no need to 
send the announcement signalling to the serving cell prior to performing the cell reselection. The MS should perform 
unannounced cell reselection also when the selected neighbour cell's "Cell reselection types supported" indicates that 
expedited cell reselection is recommended. The MS may attempt to recover the CMCE and SNDCP connections on the 
new cell. 
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Announced cell reselection is used when the MS informs the serving cell prior to the cell change, and attempts to 
restore the call(s) upon arrival at the new serving cell. This maximizes the probability of restoring the CMCE and 
SNDCP connections on the new cell. Announced cell reselection is divided into three categories to reflect different 
levels of SwMI and MS functionality. 

Type 3 reselection is provided for MSs which are unable to perform background scanning of a selected neighbour cell, 
and which must therefore break the call(s) for a period and perform foreground scanning in order to acquire broadcast 
and synchronization information for the new cell. Upon selecting the new cell, call restoration signalling can be used to 
restore the call(s). 

Type 2 reselection requires that the MS is able to perform background scanning of a selected neighbour cell, and is 
therefore in a position to immediately switch to the new cell. In type 2 the SwMI does not direct the MS to a channel in 
the new cell. The MS selects the MCCH on the new cell and performs call restoration signalling and may then be 
allocated a traffic channel upon successful completion of this signalling. 

Type 1 reselection requires that the MS is able to perform background scanning, and that the SwMI is able to direct the 
MS from the traffic channel on the original cell to the MCCH or directly to a traffic channel on the new cell. If the 
SwMI directs the MS to MCCH, the SwMI may later allocate a traffic channel; no call restoration signalling is required 
from the MS. 

NOTE: The MS does not explicitly attempt either type 1 or type 2 cell reselection. The MS includes the cell to 
which it intends to move in the handover request. If the MS is required to register on the new cell, and 
both the MS and the SwMI support forward registration, then the MS also includes a forward registration 
request with the handover request. It is the SwMI, not the MS, which determines whether type I or type 2 
handover is to be applied. For this reason the following clauses refer to the MS initiating "type 1/2 cell 
reselection"; this indicates that the MS has included the cell to which it intends to move in the handover 
request. 

Unannounced and the three types of announced cell reselection shall apply to an MS engaged in a circuit mode call. 

All MS-MLE shall support undeclared, unannounced and announced type 3 cell reselection. An MS-MLE may also 
support announced type 1/2 cell reselection. It is not necessary for the SwMI to know which type of cell reselection 
procedures the MS can support in order for these procedures to work. The MS shall determine which types of 
reselection are supported by the SwMI from the neighbour cell information element transmitted in the 
D-NWRK-BROADCAST PDU. 

If the SwMI does not support neighbour cell information in the D-NWRK-BROADCAST PDU transmission (see 
clause 18.3.6), the SwMI shall only be able to support undeclared, unannounced and announced type 3 cell reselection. 

If the SwMI supports neighbour cell information in the D-NWRK-BROADCAST PDU transmission, the MS shall 
attempt announced type 1/2 cell reselection only to a neighbour cell contained in the D-NWRK-BROADCAST PDU. 
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1 8.3.4.7.1 Determination of which type of reselection to apply 

The decision tree for deciding which cell reselection type to use is shown in figure 18.6. 



valid ranking list available 
and preferred cell identified 



apply undeclared 
cell reselection 
(Seel 8.3.4.7.2) 



true 




true 



apply unannounced 
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(See 18.3.4.7.3) 



group call 
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individual 
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NOTE: If there is no circuit mode in progress, MLE applies undeclared cell reselection and, if SNDCP is in thie 
READY-temporary break state and has data awaiting transmission, the MS SNDCP sends the SwMI an 
SN-RECONNECT PDU, refer to clause 28.3.4.2. 

Figure 18.6: Decision tree to chioose reselection type 

The MS shall normally perform cell reselection as a result of building a ranking list from monitoring or scanning of 
neighbour cells. From the neighbour cell measurements, one of the cell reselection criteria defined in clause 18.3.4.7.0 
may be met causing cell reselection to be initiated. The cell chosen as the one to which the MS will attempt to select is 
known as the preferred neighbour cell. 

In the case where the MS has knowledge of the neighbour cells (e.g. from the D-NWRK-BROADCAST PDU or from 
scanning or pre-programmed at subscription), but has not yet built a valid ranking list, serving cell radio link failure 
may occur or the maximum path delay may be exceeded. If this happens, the MS shall apply undeclared cell reselection 
if not currently participating in a circuit mode. If the MS is participating in a call or data transfer, the MS shall apply 
unannounced cell reselection. 

If the MS has no knowledge of neighbour cells, the MS should apply cell reselection according to initial cell selection 
procedures, and then on the new cell the MS shall apply undeclared cell reselection procedure if not currently 
participating in a circuit mode call. If the MS is participating in a call, the MS may apply either unannounced or 
undeclared cell reselection procedure. 
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The MS shall initiate cell reselection subject to the criteria specified in clause 18.3.4.7.0. It shall determine which type 
of reselection is to be applied from figure 18.6. The type of reselection to be employed shall depend on the following 
criteria: 

whether or not a circuit mode call transfer is in progress; 

whether radio link failure has occurred or expedited cell reselection is recommended; 

whether the call is an individual or group call; 

whether or not transmit permission has been granted; 

whether or not the MS has scanned the preferred neighbour cell. 

The cell reselection procedure is usually initiated after the MS has built a valid ranking list and one of the cell 
reselection criteria as defined in clause 18.3.4.7.0 has resulted in selection of a preferred neighbour cell. An MS shall 
scan the preferred neighbour cell before it can select that cell. If the MS can perform background scanning of a 
preferred neighbour cell, then it may attempt to use announced type 1/2 cell reselection. Otherwise, the MS shall use 
unannounced or announced type 3 cell reselection. 

If the MS has performed background scanning of a preferred neighbour cell, and the decision tree in figure 18.6 
indicates that announced type 1/2 cell reselection may be used, then it is recommended that the MS uses announced 
type 1/2 cell reselection. Otherwise, the MS shall use unannounced or announced type 3 cell reselection. 

The SwMI chooses if type 1 or 2 cell reselection is to be applied, depending on its capabilities. If the new cell does not 
support forward registration (as indicated in the cell reselection types supported information element broadcast as part 
of the D-NWRK-BROADCAST PDU), or the MS does not support forward registration, and registration is required on 
the new cell, the MS shall choose the announced type 1/2 cell reselection and the SwMI shall then apply type 2 cell 
reselection. 

Where the decision tree indicates that the MS should choose type 1/2 cell reselection, and the MS attempts type 1/2 cell 
reselection, the SwMI may either: 

• respond with a type 2 cell reselection procedure causing the MS to select the MCCH and perform call 
restoration on the neighbour cell; or 



• 



direct the MS to a traffic channel (or the MCCH) on the new cell, the MS is not required to perform call 
restoration on the new cell. This is the type 1 cell reselection procedure. 



If the new cell supports forward registration, registration is required, but the MS does not support forward registration 
the SwMI will apply type 2 cell reselection caused by the MS omitting to supply a forward registration request in the 
cell reselection request. 

1 8.3.4.7.1 a Conditions determining when registration is required during cell reselection 

An MS shall be required to register when any of the following conditions are satisfied: 

• the preferred neighbour cell does not belong to the same network as the current cell; 

• the preferred neighbour cell is in a LA which is outside the current registered area of the MS and registration is 
required in the new cell as indicated in the BS service details element. The BS service details elements is either 
received as part of the neighbour cell information in the D-NWRK-BROADCAST PDU or on the new cell in 
the D-MLE-SYSINFO PDU or D-MLE-SYSINFO-Q PDU; 

• MS has received a "temporary registration" on the serving cell i.e. MS is temporarily registered, it shall 
register to the new cell even if the cell belongs to the registered area of the MS; 

• the preferred neighbour cell has its "System wide services" parameter set to "System wide services temporarily 
not supported" - the MS shall register to the new cell even if the cell belongs to the registered area of the MS. 
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18.3.4.7.2 Undeclared cell reselection 



Undeclared cell reselection shall be initiated by an MS if it is not currently involved in any circuit mode calls and one of 
the cell reselection criteria described in clause 18.3.4.7.0 is met causing a preferred neighbour cell to be selected. If cell 
reselection is initiated as a result of a radio relinquishable, radio improvable or radio usable condition, a preferred 
neighbour cell shall have been identified by the MS-MLE. This preferred neighbour cell may or may not have been 
scanned by the MS-MLE before cell reselection is initiated. If cell reselection is initiated as a result of serving cell radio 
link failure, a preferred neighbour cell may not yet have been identified. 

Upon initiation of the undeclared cell reselection procedure, the MS-MLE shall perform the following actions: 

a) issue MLE-BREAK indication primitive, informing the higher layer 3 entities, SNDCP and CMCE, that the 
radio link to the current serving cell is unavailable for C-plane signalling; 

b) if no preferred neighbour cell has been selected, initiate foreground scanning of neighbour cells to select a 
preferred neighbour cell; 

c) if a preferred neighbour cell has been selected and background scanning of the preferred cell has not been 
performed, initiate foreground scanning of the preferred cell to confirm the selection; 

d) issue TL-SELECT request primitive via the TLC-S AP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm primitive once the new cell has been selected; 

e) where the MS does not support advanced link roaming, locally disconnect any advanced links by issuing 
TL-RELEASE request primitive via the TLA-SAP to layer 2. 

Registration shall be required if the conditions specified in 18.3.4.7.1a are satisfied: 

If registration is required, MLE shall issue MLE-LINK indication primitive to MM. MM shall indicate successful 
registration by issuing MLE-UPDATE request primitive to MLE confirming the cell. If registration was successful or if 
no registration was necessary, MLE shall send MLE-REOPEN indication primitive to the upper layer 3 entity CMCE, 
to indicate that the radio link is once again available for C-plane signalling. MLE shall send MLE-RESUME indication 
primitive to SNDCP, to indicate that the radio link is once again available for C-plane signalling. 

If the registration is to a cell which has its "System wide services" parameter set to "System wide services temporarily 
not supported" and the registration is accepted with a Location update accept type value of "Temporary registration" 
then the MS shall consider itself to be temporarily registered. 

If the registration result indicates "Cell Rejected", the MLE shall: 

• if the rejected cell is the only cell available, the MLE shall re-apply cell reselection procedures; or 



• 



if the rejected cell is not the only cell available, the MLE shall remove the rejected cell from the ranking list 
and may attempt to select another cell from the ranking list and re-apply cell reselection procedures. The 
rejected cell may only be included again in the ranking list as a result of an attempted reselection to another 
cell or until the MS is next powered on. 

If the registration result indicates "LA Rejected", the MLE shall remove all cells with the LA in this MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected LA may be included in the ranking list again when one of the 
following conditions apply: 

• after successful location update to a cell in a different LA; 

• until the MS is next powered on. 

NOTE: Cells with the rejected LA may also be included in the ranking list again after a suitable time or when the 
LA becomes available through the use of a "denied LA list". An MS may manage such a list, for example, 
to avoid oscillating between two rejected cells. 

If the registration result indicates "System Rejected", the MLE shall remove all cells with the rejected MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected MNC/MCC may be included in the ranking list again after 
an attempted reselection to a cell with a different MNC/MCC or until the MS is next powered on. 
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SNDCP may re-establish packet data communications as described in clause 28.3.4.2 by re-establishing advanced links 
on the new cell. Where the MS supports advanced link roaming, SNDCP may attempt to reconnect advanced links as 
described in clause 28.3.4.4. 

18.3.4.7.3 Unannounced cell reselection 

Unannounced cell reselection shall be initiated by an MS if one of the cell reselection criteria described in 
clause 18.3.4.7.0 is met and unannounced cell reselection is chosen according to the decision tree in figure 18.6. If cell 
reselection is initiated as a result of a radio relinquishable, radio improvable or radio usable condition, a preferred 
neighbour cell shall have been identified by the MS-MLE. This preferred neighbour cell may or may not have been 
scanned by the MS-MLE before cell reselection is initiated. If cell reselection is initiated as a result of serving cell radio 
link failure, a preferred neighbour cell may not yet have been identified. 

Upon initiation of the unannounced cell reselection procedure, the MS-MLE shall perform the following actions: 

a) issue MLE-BREAK indication primitive, informing the higher layer 3 entities, SNDCP and CMCE, that the 
radio link to the current serving cell is unavailable for C-plane signalling; 

b) where the MS does not support advanced link roaming, locally disconnect any advanced links by issuing 
TL-RELEASE request primitive via the TLA-SAP to layer 2; 

c) if no preferred neighbour cell has been selected, initiate foreground scanning of neighbour cells to select a 
preferred neighbour cell; 

d) if a preferred neighbour cell has been selected and background scanning of the preferred cell has not been 
performed, initiate foreground scanning of the preferred cell to confirm the selection; 

e) issue TL-SELECT request primitive via the TLC-S AP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm primitive once the new cell has been selected. 

Registration shall be required if the conditions specified in 18.3.4.7.1a are satisfied. 

If registration is required, MLE shall issue MLE-LINK indication primitive to MM. 

If the registration is to a cell which has its "System wide services" parameter set to "System wide services temporarily 
not supported" and the registration is accepted with a Location update accept type value of "Temporary registration" 
then the MS shall consider itself to be temporarily registered. 



£75/ 



433 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



CMCE 



MM 



MLE 





MLE-BREAK ind 




MLE-LINK ind 


MLE-UNITDATA req 


(U-LOCATION UPDATE DEMAND 
^ MLE-UNITDATA ind 


(D-LOCATION UPDATE ACCEPT 
MLE-UPDATE req ^ 


MLE-RESUME ind 




MLE-RESTORE req _^ 




(U-CALL-RESTORE) ^^ 
MLE-RESTORE con 




(D-CALL-RESTORE) 



TL-CONFIGURE req _ 




air interface 


TL-SCAN req 


^ TL-SCAN-REPORT ind 


TL-SELECT req _ 


TL-SELECT con 


U-MLE-UNITDATA 


D-MLE-UNITDATA 






U-RESTORE 






D-RESTORE-ACK 













Figure 18.7: Unannounced cell reselection procedure 

If the registration result indicates "Cell Rejected", the MLE shall: 

• if the rejected cell is the only cell available, the MLE shall re-apply cell reselection procedures; or 

• if the rejected cell is not the only cell available, the MLE shall remove the rejected cell from the ranking list 
may attempt to select another cell from the ranking list and re-apply cell reselection procedures. The rejected 
cell may only be included again in the ranking list as a result of an attempted reselection to another cell or until 
the MS is next powered on. 

If the registration result indicates "LA Rejected", the MLE shall remove all cells with the LA in this MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected LA may be included in the ranking list again when one of the 
following conditions apply: 

• after a successful location update to a cell in a different LA; 

• until the MS is next powered on. 

NOTE 1: Cells with the rejected LA may also be included in the ranking list again after a suitable time or when the 
LA becomes available through the use of a "denied LA list". An MS may manage such a list, for example, 
to avoid oscillating between two rejected cells. 

If the registration result indicates "System Rejected", the MLE shall remove all cells with the rejected MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected MNC/MCC may be included in the ranking list again after 
an attempted reselection to a cell with a different MNC/MCC or until the MS is next powered on. 
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MM shall indicate successful registration by issuing MLE-UPDATE request primitive to MLE confirming the cell. If 
registration was successful or if no registration was necessary, MLE shall send MLE-RESUME indication primitive to 
the upper layer 3 entities, CMCE and SNDCP, to indicate that the radio link is once again available for C-plane 
signalling. 

CMCE may attempt to restore any circuit mode calls which were in existence before the cell change. CMCE shall 
restore a call by responding to the MLE-RESUME indication primitive with MLE-RESTORE request primitive, 
containing a CMCE call restoration PDU. MLE shall send a U-RESTORE PDU, containing the CMCE call restoration 
SDU using the LLC acknowledged service. The U-RESTORE PDU shall contain each of the following elements only if 
the value on the new cell is different from that on the old cell: 

• MCC; 

• MNC; 

• LA. 

NOTE 2: The MCC, MNC and LA refer to the old cell. 

If call restoration is successful, MLE shall receive a D-RESTORE ACK PDU from the SwMI which shall contain the 
CMCE downlink call restoration signalling PDU. Upon receipt of the D-RESTORE ACK PDU indicating successful 
cell reselection, MLE shall issue MLE-RESTORE confirm primitive to the CMCE. The MLE-RESTORE confirm 
primitive which is passed to CMCE shall contain the CMCE restoration signalling PDU. 

NOTE 3: CMCE may attempt to restore multiple circuit mode calls using the above restoration procedure for each 
call. Calls are restored one at a time with a call restoration signalling sequence for each one. 

NOTE 4: A successful call restoration, indicated by a D-CALL RESTORE/D-RESTORE ACK PDU, should 
include a channel allocation in the MAC header if the restored call currently has a traffic channel 
allocation. 

If the D-RESTORE FAIL PDU is received instead, it shall indicate that call restoration was unsuccessful. The "Fail 
cause" element of the D-RESTORE FAIL PDU shall contain value "Restoration cannot be done on cell". MLE shall 
then issue MLE-REOPEN indication primitive to the CMCE to indicate that the radio path is restored, but that the calls 
have not been restored. The D-RESTORE FAIL PDU shall not carry an SDU for any of the higher layer 3 entities. 

SNDCP may re-establish packet data communications as described in clause 28.3.4.2, by re-establishing advanced links 
on the new cell. Where the MS supports advanced link roaming, SNDCP may attempt to reconnect the advanced links 
as described in clause 28.3.4.4. 

1 8.3.4.7.4 Announced cell reselection - type 3 

Announced type 3 cell reselection shall be initiated by an MS if one of the cell reselection criteria described in clause 
18.3.4.7.0 is met and announced type 3 cell reselection is chosen according to the decision tree in figure 18.6. If cell 
reselection is initiated as a result of a radio relinquishable, radio improvable or radio usable condition, a preferred 
neighbour cell shall have been identified by the MS -MLE. This preferred neighbour cell may or may not have been 
scanned by the MS-MLE before cell reselection is initiated. If cell reselection is initiated as a result of serving cell radio 
link failure, or expedited cell reselection is recommended on the new cell (as indicated in a D-NWRK-BROADCAST 
PDU), announced type 3 cell reselection shall not be attempted by the MS. 

Upon initiation of the announced type 3 cell reselection procedure, the MS-MLE shall send a U-PREPARE PDU to the 
SwMI. The U-PREPARE PDU shall not contain the cell identifier element and the PDU shall not carry an SDU. 

NOTE 1: The fact that the cell identifier element is not present in the PDU informs the SwMI that a preferred 
neighbour cell has not yet been selected and that the MS-MLE is attempting announced type 3 cell 
reselection. 

MLE shall send the U-PREPARE PDU by issuing TL-DATA request primitive to layer 2 with the primitive parameters 
set as follows: 

• PDU priority shall be set to 6; 

• stealing permission shall be set to "steal immediately"; 

• the stealing repeats flag shall not be set. 
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NOTE 2: By transmitting the U-PREPARE PDU, the MS informs the SwMI that it is about to change cell. The 
SwMI should also recognize the effect of the cell change on any circuit mode calls that the MS is 
currently involved in. 
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link failure occurs, the MS shall abandon the announcement signalling and initiate the cell change procedure 
immediately. 
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Figure 18.8: Announced type 3 cell reselection procedure 

If timer, T370, expires, the MS shall immediately initiate the cell change procedure as described below. 

The SwMI shall not respond to U-PREPARE PDU with a D-PREPARE FAIL PDU in the case where the MS-MLE has 
not indicated a preferred neighbour cell in the U-PREPARE PDU. Therefore a D-PREPARE FAIL PDU shall not be a 
valid response for announced type 3 cell reselection. 
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Initiation of the cell change procedure 

Upon initiation of the cell change procedure, the MS-MLE shall: 

a) issue MLE-BREAK indication primitive, informing the higher layer 3 entities, SNDCP and CMCE, that the 
radio link to the current serving cell is unavailable for C-plane signalling; 

b) where the MS does not support advanced link roaming, locally disconnect any advanced links by issuing 
TL-RELEASE request primitive via the TLA-SAP to layer 2; 

c) initiate foreground scanning of the preferred neighbour cell (which has been selected as a result of monitoring 
and ranking) to confirm selection; 

d) issue TL-SELECT request primitive via the TLC-S AP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm primitive once the new cell has been selected. 

NOTE 4: If the BS receives a U-PREPARE PDU from an MS transmitting in a circuit mode call, the BS may 
remove the transmit permission by sending D-TX CEASED PDU to the other MS(s) in the cell. 
Alternatively, the BS may allow the MS changing cell to keep the transmit permission for a period of time 
or until it selects a new cell and restores the call on that cell. 

Registration shall be required if the conditions specified in 18.3.4.7.1a are satisfied: 

If registration is required, MLE shall issue MLE-LINK indication primitive to MM. 

If the registration is to a cell which has its "System wide services" parameter set to "System wide services temporarily 
not supported" and the registration is accepted with a Location update accept type value of "Temporary registration" 
then the MS shall consider itself to be temporarily registered. 

If the registration result indicates "Cell Rejected", the MLE shall: 

if the rejected cell is the only cell available, the MLE shall re-apply cell reselection procedures; or 



• 



• if the rejected cell is not the only cell available, the MLE shall remove the rejected cell from the ranking list 
may attempt to select another cell from the ranking list and re-apply cell reselection procedures. The rejected 
cell may only be included again in the ranking list as a result of an attempted reselection to another cell or until 
the MS is next powered on. 

If the registration result indicates "LA Rejected", the MLE shall remove all cells with the LA in this MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected LA may be included in the ranking list again when one of the 
following conditions apply: 

• after a successful location update to a cell in a different LA; 

• until the MS is next powered on. 

NOTE 5: Cells with the rejected LA may also be included in the ranking list again after a suitable time or when the 
LA becomes available through the use of a "denied LA list". An MS may manage such a list, for example, 
to avoid oscillating between two rejected cells. 

If the registration result indicates "System Rejected", the MLE shall remove all cells with the rejected MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected MNC/MCC may be included in the ranking list again after 
an attempted reselection to a cell with a different MNC/MCC or until the MS is next powered on. 

MM shall indicate successful registration by issuing MLE-UPDATE request primitive to MLE confirming the cell. If 
registration was successful or if no registration was necessary, MLE shall send MLE-RESUME indication primitive to 
the upper layer 3 entities, CMCE and SNDCP, to indicate that the radio link is once again available for C-plane 
signalling. 
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CMCE may attempt to restore any circuit mode calls which were in existence before the cell change. CMCE shall 
restore calls by responding to the MLE-RESUME indication primitive with MLE-RESTORE request primitive, 
containing a CMCE call restoration PDU. MLE shall send a U-RESTORE PDU, containing the CMCE call restoration 
SDU using the LLC acknowledged service. The U-RESTORE PDU shall contain each of the following elements only if 
the value on the new cell is different from that on the old cell: 

• MNC; 

• MCC; 

• LA. 

If call restoration is successful, MLE shall receive a D-RESTORE ACK PDU from the SwMI which shall contain the 
CMCE downlink call restoration signalling PDU. Upon receipt of the D-RESTORE ACK PDU indicating successful 
cell reselection, MLE shall issue MLE-RESTORE confirm primitive to the CMCE. The MLE-RESTORE confirm 
primitive which is passed to CMCE shall contain the CMCE restoration signalling PDU. 

NOTE 6: CMCE may attempt to restore multiple circuit mode calls using the above restoration procedure for each 
call. Calls are restored one at a time with a call restoration signalling sequence for each one. 

If the D-RESTORE FAIL PDU is received instead, it shall indicate that call restoration was unsuccessful. The "Fail 
cause" element of the D-RESTORE FAIL PDU shall contain value "Restoration cannot be done on cell". MLE shall 
then issue MLE-REOPEN indication primitive to the CMCE to indicate that the radio path is restored, but that the call 
has not been restored. The D-RESTORE FAIL PDU shall not carry an SDU for any of the higher layer 3 entities. 

SNDCP may re-establish packet data communications as described in clause 28.3.4.2, by re-establishing advanced links 
on the new cell. Where the MS supports advanced link roaming, SNDCP may attempt to reconnect the advanced links 
as described in clause 28.3.4.4. 

18.3.4.7.5 Announced cell reselection types 1 and 2 

Announced type 1/2 cell reselection shall be initiated by an MS if one of the cell reselection criteria described in clause 
18.3.4.7.0 is met and announced type 1/2 cell reselection is chosen according to the decision tree in figure 18.6. A 
preferred neighbour cell shall have been identified by the MS-MLE and shall have been scanned prior to initiating the 
cell reselection procedure. If cell reselection is initiated as a result of serving cell radio link failure, if expedited cell 
reselection is recommended on the new cell (as indicated in a D-NWRK-BROADCAST PDU), or if the preferred 
neighbour cell has not yet been scanned, announced type 1/2 cell reselection shall not be attempted by the MS. 
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Figure 18.9: Decision tree to identify thie type 1/2 reselection type applied by the SwMI 

Upon initiation of the announced type 1/2 cell reselection procedure, the MS shall determine if registration is required 
in the new cell, refer to figure 18.9. 

Registration shall be required if the conditions specified in 18.3.4.7.1a are satisfied: 

If registration is required, the MS supports forward registration, and the "cell reselection types supported" information 
element in the "neighbour cell information" information element within the D-NWRK BROADCAST PDU indicates 
that the new cell supports forward registration, then the MLE shall issue MLE-LINK indication primitive to MM which 
shall have the following parameters: 

• MCC of the preferred neighbour cell; 

• MNC of the preferred neighbour cell; 

• LA of the preferred neighbour cell; 

• registration type shall be set to "forward" to indicate that forward registration (i.e. registration in a cell other 
than the current serving cell) is required. 
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Upon initiation of the announced cell reselection type 1/2 procedure, the MS-MLE shall send a U-PREPARE PDU to 
the SwMI. If registration is required, the MS supports forward registration, and the "cell reselection types supported" 
information element in the "neighbour cell information" information element within the D-NWRK BROADCAST PDU 
indicates that the new cell supports forward registration, then the U-PREPARE PDU shall carry a U-LOCATION 
UPDATE DEMAND SDU. The U-PREPARE PDU shall contain the cell identifier element which shall uniquely 
identify a cell as defined by the D-NWRK-BROADCAST PDU. 

The MS may combine an OTAR CCK request with the cell reselection by including either a U-OTAR CCK DEMAND 
PDU within the U-PREPARE PDU or requesting the CCK within the U-LOCATION UPDATE DEMAND PDU as 
described in clause 4.5.1.3 of EN 300 392-7 [8]. 

NOTE 1: The fact that the U-PREPARE PDU contains details which identify a preferred neighbour cell informs the 
SwMI that the MS is attempting announced type 1/2 cell reselection. 

MLE shall send the U-PREPARE PDU by issuing TL-DATA request primitive to layer 2 with the primitive parameters 
set as follows: 

• PDU priority shall be set to 6; 

• stealing permission shall be set to "steal immediately"; 

• the stealing repeats flag shall not be set. 

NOTE 2: By transmitting the U-PREPARE PDU, the MS informs the SwMI that it is about to change cell. The 
SwMI should also recognize the effect of the cell change on any circuit mode calls that the MS is 
currently involved in. 

MLE shall start timer, T370, and shall await the response from the SwMI. The SwMI shall respond with 

a D-NEW-CELL PDU with the channel command valid element set either to "Change channel immediately", "No 

channel change" or "Follow MAC channel change". 

If forward registration was requested, the SwMI may or may not accept registration on the new cell. If forward 
registration was requested, and the SwMI accepts the registration, the D-NEW-CELL PDU shall contain an MM SDU 
accepting registration on the new cell. On receipt in the MS, the MM SDU shall be passed to MM using a 
MLE-PREPARE confirm primitive. A MLE-UPDATE request primitive shall then indicate successful registration to 
MLE. 

NOTE 3: The SwMI controls whether type 1 or type 2 cell reselection is to be applied: generally, this is 

independent of whether the MS attempts forward registration.If the MS is required to register on the new 
cell, and it does not attempt to forward register, then the SwMI applies type 2 cell reselection: the MS 
registers on arrival in the new cell prior to call restoration. 

The MS may receive OTAR CCK information from either a D-OTAR CCK PROVIDE PDU or D-LOCATION 
UPDATE ACCEPT PDU, within the D-NEW-CELL PDU, and process it as described in clause 4.5.1.3 of 
EN 300 392-7 [8]. 

If the SwMI responds to the U-PREPARE PDU with a D-NEW-CELL PDU which has the "Channel command valid" 
element set to "No channel change", MLE shall restart timer T370 and shall wait for a further D-NEW-CELL PDU 
from the SwMI. The "No channel change" D-NEW-CELL PDU shall not contain a MM SDU. 

Following the initial "No channel change" D-NEW-CELL PDU, the SwMI may continue to refresh timer T370 by 
sending further "No channel change" D-NEW-CELL PDUs. A "Change channel immediately" or "Follow MAC 
channel change" D-NEW-CELL PDU, received after a "No channel change" D-NEW-CELL PDU, shall contain a MM 
SDU and cause processing to continue, as described below, as if only a single D-NEW-CELL PDU containing "Change 
channel immediately" or "Follow MAC channel change" respectively has been received. 

If cell reselection is successful, the SwMI responds to the cell reselection preparation with a D-NEW-CELL PDU, that 
shall contain a MM SDU. The "Channel command valid" element is set to either "Change channel immediately" or 
"Follow MAC channel change". The content of the "Channel command valid" element of the D-NEW-CELL PDU 
defines the type of cell reselection that the SwMI is applying. These options are described below: 
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Figure 18.10: Announced type 2 cell reselection procedure, registration required, 

successful forward registration 
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Figure 18.11: Announced type 2 cell reselection procedure, registration required, 

no forward registration 
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Figure 18.12: Announced type 2 cell reselection procedure, registration required, 

failed forward registration 
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Figure 18.13: Announced type 2 cell reselection procedure, no registration required 

If the Channel command vahd element in the D-NEW-CELL PDU is set to "Change channel immediately" this shall 
cause the MS to switch autonomously to the MCCH of the new cell, reset T370 and initiate the cell change procedure as 
follows: 

a) issue MLE-BREAK indication primitive, informing the higher layer 3 entities, SNDCP and CMCE, that the 
radio link to the current serving cell is unavailable for C-plane signalling; 

b) where the MS does not support advanced link roaming, locally disconnect any advanced links by issuing 
TL-RELEASE request primitive via the TLA-SAP to layer 2; 

c) issue TL-SELECT request primitive via the TLC-S AP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm primitive once the new cell has been selected; 

d) issue MLE-RESUME indication primitive to the upper layer 3 entities, CMCE and SNDCP to indicate that the 
radio link is once again available for C-plane signalling. 

If registration is required, and the MS did not attempt forward registration, MLE shall issue an MLE-LINK indication 
primitive to MM. 

If the registration is to a cell which has its "System wide services" parameter set to "System wide services temporarily 
not supported" and the registration is accepted with a Location update accept type value of "Temporary registration" 
then the MS shall consider itself to be temporarily registered. 

If the registration result indicates "Cell Rejected", the MLE shall: 

• if the rejected cell is the only cell available, the MLE shall re-apply cell reselection procedures; or 

• if the rejected cell is not the only cell available, the MLE shall remove the rejected cell from the ranking list 
and may attempt to select another cell from the ranking list and re-apply cell reselection procedures. The 
rejected cell may only be included again in the ranking list as a result of an attempted reselection to another 
cell or until the MS is next powered on. 
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If the registration result indicates "LA Rejected", the MLE shall remove all cells with the LA in this MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected LA may be included in the ranking list again when one of the 
following conditions apply: 

• after successful location update to a cell in a different LA; 

• until the MS is next powered on. 

NOTE 4: Cells with the rejected LA may also be included in the ranking list again after a suitable time or when the 
LA becomes available through the use of a "denied LA list". An MS may manage such a list, for example, 
to avoid oscillating between two rejected cells. 

If the registration result indicates "System Rejected", the MLE shall remove all cells with the rejected MNC/MCC from 
the ranking list. The MLE may attempt to select another cell from the ranking list and re-apply cell reselection 
procedures. In all registration cases, cells with the rejected MNC/MCC may be included in the ranking list again after 
an attempted reselection to a cell with a different MNC/MCC or until the MS is next powered on. 

MM shall indicate successful registration by issuing MLE-UPDATE request primitive to MLE confirming the cell. If 
registration was successful or if no registration was necessary, MLE shall send MLE-RESUME indication primitive to 
the upper layer 3 entities, CMCE and SNDCP, to indicate that the radio link is once again available for C-plane 
signalling. 

CMCE may attempt to restore any circuit mode calls which were in existence before the cell change. CMCE shall 
restore calls by responding to the MLE-RESUME indication primitive with MLE-RESTORE request primitive, 
containing a CMCE call restoration PDU. MLE shall send a U-RESTORE PDU, containing the CMCE call restoration 
SDU using the LLC acknowledged service. The U-RESTORE PDU shall contain each of the following elements only if 
the value on the new cell is different from that on the old cell: 

• MCC; 

• MNC; 

• LA. 

If call restoration is successful, MLE shall receive a D-RESTORE ACK PDU from the SwMI which shall contain the 
CMCE downlink call restoration signalling PDU. Upon receipt of the D-RESTORE ACK PDU indicating successful 
cell reselection, MLE shall issue a MLE-RESTORE confirm primitive to CMCE. The MLE-RESTORE confirm 
primitive which is passed to CMCE shall contain the CMCE restoration signalling PDU. 

NOTE 5: CMCE may attempt to restore multiple circuit mode calls using the above restoration procedure for each 
call. Calls are restored one at a time with a call restoration signalling sequence for each one. 

If the D-RESTORE FAIL PDU is received instead, it shall indicate that call restoration was unsuccessful. The "Fail 
cause" element of the D-RESTORE FAIL PDU shall contain value "Restoration cannot be done on cell". MLE shall 
then issue MLE-REOPEN indication primitive to the CMCE to indicate that the radio path is restored, but that the call 
has not been restored. The D-RESTORE FAIL PDU shall not carry an SDU for any of the higher layer 3 entities. 

SNDCP may re-establish packet data communications as described in clause 28.3.4.2, by re-establishing advanced links 
on the new cell. Where the MS supports advanced link roaming, SNDCP may attempt to reconnect the advanced links 
as described in clause 28.3.4.4. 
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Figure 18.14: Announced type 1 cell reselection procedure, with forward registration 
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Figure 18.15: Announced type 1 cell reselection procedure, forward registration not required 

If the "Channel command vaHd" element in the D-NEW-CELL PDU is set to "Follow MAC channel allocation" this 
indicates that a TCH has been allocated on the new cell to continue the circuit mode call, or that the MS has to switch to 
the MCCH of the new cell to continue the call. Upon reception of a D-NEW-CELL PDU, MS-MLE shall initiate the 
cell change procedure as follows: 

a) issue MLE-BREAK indication primitive, informing the higher layer 3 entity, SNDCP, that the radio link to the 
current serving cell is unavailable for C-plane signalling; 

b) where the MS does not support advanced link roaming, locally disconnect any advanced links by issuing 
TL-RELEASE request primitive via the TLA-SAP to layer 2. 

c) receive a TL-SELECT indication, indicating the channel change, and respond with a TL-SELECT response. 

d) issue MLE-RESUME indication primitive to SNDCP to indicate that the radio link is once again available for 
C-plane signalling. 
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The MAC shall automatically follow the channel allocation in the MAC header. The MAC indicates the channel change 
using TL-SELECT indication primitive to which the MLE shall respond with TL-SELECT response primitive 
containing a parameter to inform the MAC of the main carrier frequency on the new cell (see clause 20.3.4.5.8). On 
receiving TL-SELECT indication primitive indicating that the channel change has been completed by the MAC, the 
MLE shall send indication to SNDCP to indicate that the radio link is once again available for C-plane signalling. The 
MS shall continue the call on the new cell assuming the same U-plane/C -plane mode and transmit permission as it had 
on the old cell unless it has been directed to the MCCH on the new cell (i.e. the MS shall not assume that U-plane mode 
continues on MCCH); 

NOTE 6: In this case, there is no need for the MS to send call restoration signalling on the new cell. If the SwMI 
directs the MS to the MCCH, the SwMI should then later complete the call restoration by directing the 
MS to a traffic channel. 

SNDCP may re-establish packet data communications as described in clause 28.3.4.2 of the present document, by 
re-establishing advanced links on the new cell. Where the MS supports advanced link roaming, SNDCP may attempt to 
reconnect the advanced links as described in clause 28.3.4.4 of the present document. 

1 8.3.4.7.6 Unsuccessful type 1/2 cell reselection 

If while waiting for a D-NEW-CELL PDU from the SwMI, a serving cell radio link failure occurs or timer T370 
expires, the MS shall abandon the announcement signalling and shall immediately initiate the cell change procedure 
described in clause 18.3.4.7.5. 

Following the initial "No channel change" D-NEW-CELL PDU, the SwMI may continue to refresh timer T370 by 
sending further "No channel change" D-NEW-CELL PDUs. However, it is recommended that the total amount of time 
the SwMI keeps the MS waiting for a D-NEW-CELL PDU with "Channel command valid" element set to "Change 
channel immediately" or "Follow MAC channel change" is less than the duration of timer T351 (the registration 
response time) - refer to clause 16.n.LL The MS shall abandon the announcement signalling and shall immediately 
initiate the cell change procedure described in 18.3.4.7.5. 

If cell reselection was attempted but is not successful, the SwMI shall respond to the MS with a D-PREPARE FAIL 
PDU which shall carry an MM PDU rejecting registration on the new cell. The "Fail cause" element of the 
D-PREPARE FAIL PDU may contain any of the values specified in clause 18.5.7, "Fail cause". 

If the "Fail cause" element of the D-PREPARE FAIL PDU contains the value "Temporary break in service", "Cell 
reselection type not supported" or "Restoration cannot be done on cell", the "Reject cause" element of the 
D-LOCATION UPDATE REJECT PDU shall have value "Forward registration failure". 

If the "Fail cause" element of the D-PREPARE FAIL PDU contains the value "MS not allowed on cell" then the "Reject 
cause" element of the D-LOCATION UPDATE REJECT PDU shall have any value other than "Forward Registration 
failure". 

The MM SDU shall be passed to MM using an MLE-PREPARE confirm primitive. MLE-UPDATE request primitive 
shall then inform MLE that the cell reselection was not successful.If the MS-MLE receives a D-PREPARE FAIL PDU 
from the SwMI, the MS-MLE may attempt announced cell reselection to another neighbour cell in the ranking list 
which meets one of the cell reselection criteria described in clause 18.3.4.7.0. The "Fail cause" element of the 
D-PREPARE FAIL PDU shall contain the value "Restoration cannot be done on cell", "Temporary break in service" or 
"MS not allowed on cell". 

If the fail cause is "MS not allowed on cell": 

• If forward registration was not attempted, or the reject cause indicates "Cell Rejection" (refer to 

clause 16.10.42), MM shall stay registered on the current serving cell. MLE shall remove the rejected cell 
from the ranking list; if, following this action, the ranking list still contains other cells, MLE may attempt to 
select another cell from the list and reapply cell reselection procedures. The rejected cell may only be included 
again in the ranking list as a result of an attempted reselection to another cell or when the MS is next powered 
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• If forward registration was attempted, and the reject cause indicates "LA Rejection" (refer to clause 16.10.42), 
the MLE shall remove all cells in the LA with this MNC/MCC from the ranking list. The MM shall stay 
registered on the current serving cell. The MLE may attempt to select another cell from the ranking list and 
re-apply cell reselection procedures. In all registration cases, cells with the rejected LA may be included in the 
ranking list again when one of the following conditions apply: 

after a successful location update to a cell in a different LA; 

until the MS is next powered on. 

NOTE 7: Cells with the rejected LA may also be included in the ranking list again after a suitable time or when the 
LA becomes available through the use of a "denied LA list". An MS may manage such a list, for example, 
to avoid oscillating between two rejected cells. 

• If forward registration was attempted, and the reject cause indicates "System Rejection" (refer to 

clause 16.10.42), the MLE shall remove all cells, with the rejected MNC/MCC, from the ranking list. The MS 
remains registered on the current serving cell. The MLE may attempt to select another cell from the ranking 
list and re-apply cell reselection procedures. In all registration cases, cells with the rejected MNC/MCC may 
be included in the ranking list again after an attempted reselection to a cell with a different MNC/MCC or until 
the MS is next powered on. 

If the fail cause is "Restoration cannot be done on cell" (i.e. cell reselection has failed for call-related reasons), either: 

• MM shall stay registered on the current serving cell and, if the rejected cell is not the only cell in the ranking 
list, MLE may attempt to select another cell from the list and re-apply cell reselection procedures. MLE shall 
not remove the rejected cell from the ranking list but if the rejected cell is chosen as the preferred neighbour 
cell again during this cell reselection procedure, announced or unannounced cell reselection should not be 
attempted to that cell; or 

• MLE may, if the rejected cell is the only cell in the ranking list, force the call associated with the cell 
reselection to be dropped and then select the rejected cell using the undeclared cell reselection procedures 
defined in clause 18.3.4.7.2. 

NOTE 8: If the call is dropped, the MS should send a U-DISCONNECT PDU on the old cell in case the MS is the 
call owner of a group call or a party in an individual call. 

If the fail cause is "Temporary break in service", (i.e. cell reselection has failed for network related reasons e.g. there 
are no free traffic channels on the new cell) either: 

• MM shall stay registered on the current serving cell and, if the rejected cell is not the only cell in the ranking 
list, MLE may attempt to select another cell from the list and re-apply cell reselection procedures. MLE shall 
not remove the rejected cell from the ranking list but if the rejected cell is chosen as the preferred neighbour 
cell again during this cell reselection procedure, announced cell reselection type 1/2 should not be attempted to 
that cell; or 

• MLE may, if the rejected cell is the only cell in the ranking list, attempt announced type 3 or unannounced cell 
reselection to the rejected cell using the procedures defined in clauses 18.3.4.7.4 or 18.3.4.7.3. 

If the fail cause is "Cell reselection type not supported", (i.e. forward registration has failed for network related 
reasons), the MS-MLE shall issue a MLE-BREAK indication primitive to inform the higher layer 3 entity CMCE that 
the radio link to the current serving cell is unavailable for C-plane signalling and shall then proceed with the initiation 
of the cell change procedure including registration and call restoration on the new cell as defined in 18.3.4.7.4. 

All other combinations of the D-NEW-CELL/D -PREPARE FAIL PDU and MM registration PDUs shall not be sent by 
the SwMI during announced type 1 cell reselection. 

1 8.3.4.8 Change of broadcast parameters by the SwMI 

Changes in broadcast parameters by the SwMI affects the behaviour of the MS. The broadcast parameters that affect 
MLE and the other layer 3 entities are obtained from the SYSINFO and SYSINFO-Q PDUs. The parameters fall into 
two categories: 

• information about the general services that are supported by the SwMI on a particular cell e.g. BS service 
details; 
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• information concerning the security services that are supported by the SwMI on a particular cell e.g. security 
information in extended services broadcast. 

The behaviour of the MS is dependent upon the broadcast parameter that has changed. MLE shall determine if the 
parameter(s) that has changed requires the MS to re-register, whereby MLE shall issue a MLE-LINK indication 
primitive to MM. 

If the status of the cell changes from "System wide services temporarily not supported" to "Normal mode" and the MS 
is temporarily registered with the cell then the MLE shall indicate a need for periodic registration to MM. 

The behaviour of the MS when there is a change in the security parameters is defined in EN 300 392-7 [8]. 

In addition to the above, MLE shall inform MM, CMCE and SNDCP of the change in broadcast parameter(s) via a 
MLE-INFO indication primitive. 

18.3.4.9 Assigned channel replacement on the serving cell 

This clause describes when and how an MS may request the SwMI to replace an assigned channel on the serving cell. 
Clauses 18.3.4.9 to 18.3.4.9.10 apply only to MSs which support the use of non-conforming channels. 
Clause 18.3.4.9.11 applies to MSs which support the use of non-conforming channels and also applies to MSs which 
support data priority. 

1 8.3.4.9.1 Types of assigned channels 

The assigned channel replacement request procedure allows the MS to request replacement of an assigned channel by a 
channel offering greater packet data throughput (e.g. at short range) or greater reliability (e.g. at long range). It also 
enables the MS to request a sector change in cells where the SwMI employs sectored channels controlled by a single 
MCCH. 

A SwMI may offer the following types of assigned channels: 

• A "conforming channel" has the same azimuthal radiation pattern as the main carrier, is radiated from the same 
site as the main carrier and has the same range (measured by the CI path loss parameter) as the main carrier. It 
is a special case of a concentric channel. A channel which is not a conforming channel is called a 
non-conforming channel. 



• 



A "concentric channel" has the same azimuthal radiation pattern as the main carrier and is radiated from the 
same site. It may use a different modulation mode, RF bandwidth and RF power to the main carrier and may 
have a higher or lower range and coverage area than the main carrier (i.e. it may be a non-conforming 
channel). Where the SwMI offers multiple concentric channels with different RF characteristics, a concentric 
channel offering a higher bandwidth will generally have a shorter range. A "channel class" is defined as a set 
of values indicating the general RF characteristics of a concentric channel (see clause 18.5.5b). A cell may 
offer more than one individual concentric channel belonging to the same channel class. The MS predicts the 
performance of a channel class from measurements on a current channel (see clause 18.3.4.9.2) or by 
monitoring the main carrier (see clause 18.3.4.9.3) and advises the SwMI of the channel classes which it can 
currently use (see clauses 18.3.4.9.10 and 18.3.4.9.11). 

• A "sectored channel" has a different azimuthal radiation pattern to the main carrier, and is radiated from the 
same site. It is a non-conforming channel and is not a concentric channel. The MS cannot predict the 
performance of a sectored channel by measurements on any other channel. The MS discovers which sectored 
channels it can use by monitoring each sectored channel (see clause 18.3.4.9.6) and advises the SwMI of the 
sectored channels which it can currently use (see clauses 18.3.4.9.10 and 18.3.4.9.11). 

NOTE 1 : A 7t/4-DQPSK channel is normally a conforming channel. 

NOTE 2: The present document does not support use of channels which are transmitted by the SwMI from a 
different location to the main carrier. 

The MS -MLE discovers if a cell supports the use of non-conforming channels by reception of a 
D-NETWORK-BROADCAST-EXTENSION PDU indicating the presence of non-conforming channels on that cell. 
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The MS-MLE is informed by layer 2 about whether an assigned channel is a conforming channel, a 
non-conforming concentric channel or a sectored channel by the channel information parameter in the TL-SELECT 
indication primitive. 

The MS-MLE discovers which channel classes are available by inspection of the 

D-NWRK-BROADCAST-EXTENSION PDU. The characteristics of each available channel class are given in the 
"channel class" and "neighbour cell channel classs" information elements. A cell may possess more than one channel of 
a particular channel class, but the MS-MLE is only interested in the existence of a channel class, not in the individual 
channels of that channel class. 

The MS-MLE discovers which sectored channels are provided by inspection of the 

D-NWRK-BROADCAST-EXTENSION PDU. The characteristics of each sectored channel are given in the 
"sectored channel detail" information element. Each sectored channel is described individually so that the MS has 
enough information to monitor it. 

There is no requirement for the SwMI to advertise the existence of channel classes with the same or greater coverage 
area than the main carrier (including conforming channel classes) in the D-NWRK-BROADCAST-EXTENSION PDU. 
The SwMI assigns the MS to channels in these channel classes without assistance from the MS. When the MS-MLE 
wishes to make an assigned channel replacement request, it may assume that a conforming channel class is available. 

1 8.3.4.9.2 Serving cell channel class assessment 

Serving cell channel class assessment is the procedure whereby the MS assesses the quality of channel classes on the 
serving cell from measurements on the current channel or channels. 

Serving cell channel class assessment is not required for conforming channel classes or channel classes with greater 
coverage area (at the lowest modulation level) than the main carrier. 

The criteria for starting and using serving cell channel class assessment are defined in clause 18.3.4.9.8. 

If the criteria are fulfilled, the serving cell channel class assessment is started by issuing a TL- ASSESSMENT-LIST 
request primitive through the TLC-SAP informing layer 2 of the channel classes to be assessed. The parameters passed 
down with the TL-ASSESSMENT-LIST request primitive, for each channel class to be assessed, shall be a channel 
class label and the characteristics of the channel class that is to be assessed (obtained from the channel class element in 
the D-NWRK-BROADCAST-EXTENSION PDU). The lower layers return a TL-ASSESSMENT indication primitive 
containing the C4 path loss parameter for each channel class which has been assessed. C4 is defined in clause 23. 

Serving cell channel class assessment shall have been performed during the last 60 s for a measurement to be 
considered valid. 

If it is required to stop the serving cell channel class assessment process, the MLE shall issue a TL-ASESSMENT-LIST 
request primitive which does not contain a serving cell channel class as a parameter. 

1 8.3.4.9.3 Main carrier monitoring with assessment of channel classes 

Main carrier monitoring with assessment of channel classes is the procedure which allows the MS to assess the quality 
of channel classes on the serving cell from monitoring measurements on the serving cell's main carrier. 

The criteria for starting and using main carrier monitoring with assessment of channel classes are defined in 
clause 18.3.4.9.8. 

If the criteria are fulfilled, the main carrier monitoring with assessment of channel classes is started by issuing a 
TL-MONITOR-LIST request primitive through the TLC-SAP informing layer 2 of the channel to be monitored (the 
main carrier) and the channel classes to be assessed. The parameters passed down with the 

TL-MONITOR-LIST request primitive shall include the channel number of the main carrier and, for each channel class 
to be assessed, a channel class label and the characteristics of the channel class that is to be assessed (obtained from the 
channel class element in the D-NWRK-BROADCAST-EXTENSION PDU). The lower layers return a 
TL-MONITOR indication primitive containing the C2 path loss for the main carrier and the C5 path loss parameter for 
each channel class which has been assessed. C5 is defined in clause 23. 

Main carrier monitoring with assessment of channel classes shall have been performed during the last 60 s for a 
measurement to be considered valid. 
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If it is required to stop assessing a particular channel class within the main carrier monitoring with assessment of 
channel classes process, the MS-MLE shall issue a TL-MONITOR-LIST request primitive which does not contain the 
channel class for which assessment is to be stopped. If it is also required to stop monitoring the main carrier, the 
MS-MLE shall issue a TL-MONITOR-LIST request primitive which does not contain the channel number of the main 
carrier. 

1 8.3.4.9.4 Neighbour cell channel class assessment 

Neighbour cell channel class assessment is the procedure whereby the MS assesses the quality of channel classes on a 
neighbour cell. 

Neighbour cell channel class assessment is not required for conforming channel classes or channel classes with greater 
coverage area than the main carrier of that neighbour cell. 

The criteria for starting and using neighbour cell channel class assessment are defined in clause 18.3.4.9.8. 

If the criteria are fulfilled, the neighbour cell channel class assessment is started by issuing a 

TL-MONITOR-LIST request primitive or a TL-SCAN request primitive through the TLC-SAP informing layer 2 of the 

main carrier of the neighbour cell to be monitored and the channel classes to be assessed. 

The parameters passed down with the TL-MONITOR-LIST request primitive shall include the channel number of the 
neighbour cell main carrier to be monitored and the RF characteristics of the main carrier (obtained from the 
neighbour cell information element of the D-NWRK-BROADCAST PDU) and, for each channel class to be assessed, a 
channel class label and the characteristics of the channel class that is to be assessed (obtained from the neighbour cell 
channel class element in the D-NWRK-BROADCAST-EXTENSION PDU). The lower layers return a TL-MONITOR 
indication primitive containing the C5 path loss parameter for each channel class. C5 is defined in clause 23. 

The parameters passed down with the TL-SCAN request primitive shall include the channel number of the neighbour 
cell main carrier to be scanned (obtained from the neighbour cell information element of the D-NWRK-BROADCAST 
PDU) and, for each channel class to be assessed, a channel class label and the characteristics of the channel class to be 
assessed (obtained from the neighbour cell channel class element in the D-NWRK-BROADCAST-EXTENSION PDU). 
The lower layers return a TL-SCAN confirm primitive containing the C5 path loss parameter for each channel class. 

Channel class assessment shall have been performed during the last 60 s for a measurement to be considered valid. 

If it is required to stop assessing a particular channel class within the neighbour cell channel class assessment process, 
the MS-MLE shall issue a TL-MONITOR-LIST request primitive which does not contain the channel class for which 
assessment is to be stopped. If it is also required to stop monitoring the neighbour cell main carrier, the MS-MLE shall 
issue a TL-MONITOR-LIST request primitive which does not contain the channel number of the neighbour cell main 
carrier. 

NOTE: The MS-MLE may decide to use the TL-SCAN request primitive instead of the 

TL-MONITOR-LIST request primitive to initiate channel class assessment on a neighbour cell if the 
MS-MLE needs to scan the neighbour cell main carrier for another reason. 

1 8.3.4.9.5 Ranking of channel classes 

Ranking of channel classes shall be based upon the received path loss parameters CI, C4 and C5 for the channel 

classes. 

The ranking should produce a ranked channel class list. The list should always include a conforming channel class 
ranked by the path loss parameter CI or C3 derived from serving cell surveillance measurements refer to 
clause 18.3.4.3. 

This ranked list may be used for making the decision of whether and when to change channel or cell, as described in 
clause 18.3.4.9.9.5. 

18.3.4.9.6 Sectored channel monitoring 

Sectored channel monitoring allows the MS to measure the path loss parameters C2 of sectored channels using 
information about the sectored channels broadcast by the serving cell. The MS is required to directly measure the 
received power of a monitored sectored channel. The sectored channels may be on the serving cell or on a neighbour 
cell. 
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In order to be able to monitor sectored channels, the MS-MLE shall have received a 

D-NWRK-BROADCAST EXTENSION PDU containing a list of the sectored channels. The procedures concerning 
network broadcast PDUs are dealt with in clause 18.3.6. The criteria for starting and using sectored channel monitoring 
are defined in clause 18.3.4.9.8. If the criteria are fulfilled, the sectored channel monitoring is started by issuing a 
TL-MONITOR-LIST request primitive through the TLC-SAP. The TL-MONITOR-LIST request primitive informs 
layer 2 of the sectored channels to be monitored. The parameters passed down with the TL-MONITOR-LIST request 
primitive shall include the channel number and the characteristics of each channel to be monitored (obtained from the 
neighbour cell information element of the D-NWRK-BROADCAST-EXTENSION PDU). The MS-MLE shall know 
locally which channels the MS is capable of monitoring and shall not instruct the lower layers to monitor any channel 
that the MS-MLE knows to be outside the capabilities of the equipment. For each channel the lower layers return a 
TL-MONITOR indication containing the C2 path loss parameter. C2 is defined in clause 23. 

Monitoring is a background procedure and is defined in clause 23. Sectored channel monitoring shall have been 
performed during the last 60 s for a sectored channel monitoring measurement to be considered valid. 

If it is required to stop the sectored channel monitoring process, the MLE shall issue a TL-MONITOR-LIST which does 
not contain a sectored channel as a parameter. 

1 8.3.4.9.7 Ranking of monitored sectored channels 

Ranking of monitored sectored channels shall be based upon the received path loss parameters C2 from the layer 2 
monitoring process, issued in a TL-MONITOR indication primitive. 

The ranking should produce a ranked sectored channel list. This ranked channel list may be used for making the 
decision of whether and when to change sector or cell, according to clause 18.3.4.9.9.5. 

1 8.3.4.9.8 Criterion for starting and using the channel assessment and channel monitoring 
processes 

This clause applies only to MSs which support the use of non-conforming channels. 

The MS determines whether non-conforming channels or sectored channels, or both, exist on a cell from inspection of 
D-NWRK-BROADCAST-EXTENSION PDUs. 

The MS should assess the non-conforming channel classes (see clause 18.3.4.9.2) and monitor the sectored channels 
(see clause 18.3.4.9.6) on the serving cell if the MS SNDCP has requested the MS-MLE to prepare for transmitting or 
receiving packet data (as advised by a MLE-CONFIGURE request primitive from SNDCP containing an SNDCP status 
parameter set to "standing-by"). 

When the MS SNDCP advises the MLE that it is actively transmitting or receiving packet data (SNDCP status 
parameter set to "ready") the channel class assessment and sectored channel monitoring processes for channels on the 
serving cell should either be permanently enabled or should be enabled when some criterion is met, e.g. when the 
assigned channel path loss value CI falls below a pre-determined threshold, or when a TL-REPORT indication 
primitive from layer 2 indicates that channel replacement is advisable or channel replacement may be beneficial. 

When the MS-MLE needs to assess the quality of available channel classes, the MS-MLE may request layer 2 to 
perform main carrier monitoring with assessment of channel classes (see clause 18.3.4.9.3) in addition to, or instead of, 
serving cell channel class assessment. 

NOTE 1 : When the current channel is a sectored channel (indicated in the channel information parameter of the 
TL-SELECT indication primitive), main carrier monitoring with assessment of channel classes results 
(C5) are more reliable than channel class assessment results (C4). For example, C4 may be lower than C5 
(i.e. the C4 path loss may be overestimated) when the MS is near the azimuthal boundary of a sectored 
channel. If the MS-MLE relies on the C4 path loss parameter near an azimuthal boundary, the MS-MLE 
could fail to detect channel classes that are radio usable. At other times, reliance on C4 could result in the 
MS being assigned to a channel that proves to be unusable. The MS-MLE may periodically initiate main 
carrier monitoring with assessment and compare the C4 and C5 path loss parameters to decide if it is 
necessary to continue to use main carrier monitoring with assessment. 

NOTE 2: The MS is not precluded from using main carrier monitoring with channel class assessment on a 
concentric channel. 
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It is assumed that the assessment and monitoring processes may be disabled when the quality of the currently-selected 
channel rises above the threshold plus some hysteresis factor, and a TL-REPORT indication primitive from layer 2 
indicates that the current channel performance is acceptable. However, the MS may choose to continue assessment or 
monitoring if the MS requires a better service (see clause 18.3.4.9.9.5) than that provided by the current assigned 
channel. 

To assist a cell reselection decision (clause 18.3.4.5.7) and to speed selection of a suitable packet data channel after a 
cell reselection, the MS may decide to assess any channel classes on neighbour cells and monitor any sectored channels 
on neighbour cells if the MS has received a D-NWRK-BROADCAST-EXTENSION PDU indicating their existence 
and the SNDCP status is "ready" or "standing-by" and the quality of the main carrier (as indicated by CI, C2 or C3 for 
the main carrier) falls below a pre-determined threshold. 

MLE should terminate channel class assessment, main carrier monitoring and channel assessment, and sectored channel 
monitoring when SNDCP advises MLE that the SNDCP status is "idle". 

It is a designer choice for the MS to assess channel classes and monitor sectored channels on the serving cell and 
neighbour cells at other times. 

Where the channel class assessment and sectored channel monitoring processes are not permanently enabled, but started 
when a threshold value is crossed on a current channel, the threshold value should be chosen to be a value greater than 
the threshold parameters, FAST_RESELECT_THRESHOLD, SLOW_RESELECT_THRESHOLD, to allow the MS 
enough time to assess the channel classes and monitor the sectored channels and propose a new channel class or 
sectored channel prior to the complete loss of service from the current channel. 

The exact method for the selection of the thresholds and hysteresis values for starting and stopping assessment and 
monitoring is outside the scope of the present document. 

1 8.3.4.9.9 Criteria used for requesting an assigned channel replacement 

The following clauses, and also clause 18.3.4.5.3, define the criteria which shall be used to initiate the assigned channel 
replacement procedure described in clause 18.3.4.9.10. 

18.3.4.9.9.1 Data class offset 

The DATA_CLASS_OFFSET is used to adjust the decision threshold for using a channel to take account of the 
differing reliability requirements of the various data classes being transmitted and received by SNDCP. The value of 
DATA_CLASS_OFFSET depends on the data class most recently advised to the MS-MLE by SNDCP in the data class 
information parameter of the MLE-CONFIGURE request primitive. The data class information parameter in the 
MLE-CONFIGURE primitive indicates the most demanding data class currently in active use by the MS. The value of 
the DATA_CLASS_OFFSET for each data class is a MS designer choice, and may be zero, but shall not be negative. 

NOTE: The real-time data class requires better reliability than the telemetry data class, and the telemetry data 
class may require better reliability than the background data class. 

18.3.4.9.9.2 Criterion for radio relinquislnable assigned cinannel 

An assigned channel becomes radio relinquishable when the quality of the downlink radio connection falls below a 
certain level and there is another channel class or sectored channel in the same cell which has a downlink radio 
connection of sufficient quality. The following conditions shall be met in order to declare the assigned channel radio 
relinquishable: 

• the MS has been on the current assigned channel for at least time T372; and 

• either: 

the assigned channel path loss parameter CI shall, for period T374, fall below 
(FAST_CHANNEL_CHANGE_THRESHOLD + DATA_CLASS_OFFSET) and the path loss 
parameter C2 or C4 of at least one of the channel classes or sectored channels in the ranking lists for the 
serving cell shall exceed by FAST_CHANNEL_CHANGE_HYSTERESIS the path loss parameter CI of 
the assigned channel for period T374; or 

the MS-MLE is informed by a TL-REPORT indication primitive that channel replacement may be 
advisable. 
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The MS-MLE shall check the criterion for channel relinquishment as often as one channel class is assessed or one 
sectored channel is monitored and on receipt of a TL-REPORT indication primitive indicating that channel replacement 
may be beneficial or is advisable. 

18.3.4.9.9.3 Criterion for radio improvable assigned cinannel 

An assigned channel becomes radio improvable when the quality of another channel downlink radio connection on the 
serving cell exceeds that of the assigned channel by a certain amount. The following conditions shall be met in order to 
declare the assigned channel radio improvable: 

• the MS has been on the current assigned channel for at least time T372; and 

• the path loss parameter C2 or C4 of at least one of the sectored channels or channel classes in the ranking list 
for the serving cell shall exceed by SLOW_CHANNEL_CHANGE_HYSTERESIS the path loss parameter CI 
of the assigned channel for period T374; and the assigned channel's path loss parameter CI shall, for period 
T374, fall below (SLOW_CHANNEL_CHANGE_THRESHOLD + DATA_CLASS_OFFSET). 

The MS-MLE shall check the criterion for improving the assigned channel or channels as often as one channel class is 
assessed or one sectored channel is monitored and on receipt of a TL-REPORT indication primitive indicating that 
channel replacement may be beneficial. 

18.3.4.9.9.4 Criterion for radio usable channel or channel class 

A sectored channel or a channel class becomes radio usable when it has a downlink radio connection of sufficient 
quality. The following conditions shall be met in order to declare a sectored channel or a channel class radio usable: 

• the MS has been on the current assigned channel for at least time T372; and 

• the sectored channel or channel class shall, for period T374, have a path loss parameter, C2 or C4, which is 
greater than (FAST_CHANNEL_CHANGE_THRESHOLD + DATA_CLASS_OFFSET + 
FAST_CHANNEL_CHANGE_HYSTERESIS). 

The MS-MLE shall check the criterion for a channel class being usable each time the channel class is assessed and shall 
check the criterion for a sectored channel being usable each time the sectored channel is monitored. 

18.3.4.9.9.5 Criteria for initiating the assigned channel replacement procedures 

Assigned channel replacement may be requested by the MS-MLE if an assigned channel is declared radio improvable 
(as defined in clause 18.3.4.9.9.3), the SNDCP status is "ready" (as advised by the SNDCP status parameter in an 
MLE-CONFIGURE request primitive) and the service criteria as defined below are the same on both the assigned 
channel and another radio usable channel or channel class. 

If the service provided by other channels is lower than that provided by an assigned channel, the assigned channel 
replacement request may be postponed until the assigned channel is declared radio relinquishable (as defined in 
clause 18.3.4.9.9.2). 

If the service provided by another sectored channel or channel class is higher than that provided by an assigned channel, 
then a channel replacement may be requested by the MS as soon as the other sectored channel or channel class is 
declared radio usable (as defined in clause 18.3.4.9.9.4). 

Assigned channel replacement shall not be requested by the MS-MLE if the SNDCP status is not "ready". 

The following service criteria may be used to compare the service provided by an assigned channel and another 
channel: 

• bandwidth; 

• modulation mode. 

The bandwidth and modulation mode of available channel classes and individual sectored channels are broadcast in the 
D-NWK-BROADCAST-EXTENSION PDU, with the exception of channel classes which have the same or greater 
coverage area than the main carrier. 
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Using the above criteria, an MS may decide whether another sectored channel or channel class can be considered to 
offer better service than an assigned channel. The following conditions shall cause the MS to rate another sectored 
channel or channel class to have better service than an assigned channel: 

• the other sectored channel or channel class has a higher bandwidth than the assigned channel, and the MS 
requires that higher bandwidth; 

• the other sectored channel or channel class uses the QAM modulation mode, and the assigned channel uses the 
D8PSK or 7t/4-DQPSK modulation mode and the MS requires the use of the QAM modulation mode; 

• the other sectored channel or channel class uses the D8PSK modulation mode, and the assigned channel uses 
the 7t/4-DQPSK modulation mode and the MS requires the use of the D8PSK modulation mode. 

The following conditions shall cause the MS to rate another channel to have lower service than an assigned channel: 

• the other sectored channel or channel class has a lower bandwidth than the assigned channel, and the lower 
bandwidth is supported by the MS; 

• the other sectored channel or channel class uses the tc/4-DQPSK or the D8PSK (if supported by the MS) 
modulation mode, and the assigned channel uses the QAM modulation mode; 

• the other sectored channel or channel class uses the 7t/4-DQPSK modulation mode, and the assigned channel 
uses the D8PSK modulation mode. 

In these cases the MS may postpone requesting a channel replacement until the assigned channel becomes radio 
relinquishable as defined in clause 18.3.4.9.9.2. 

If a sectored channel or channel class uses a modulation mode or bandwidth which is not supported by the MS, the MS 
shall rate that sectored channel or channel class as providing no service to the MS. 

If the other channel is deemed to offer neither better service or lower service than an assigned channel, the service shall 
be deemed to equal and the MS shall initiate the assigned channel replacement procedures as soon as another sectored 
channel or channel class becomes radio improvable over the assigned channel as defined in clause 18.3.4.9.9.3. 

1 8.3.4.9.1 Assigned channel replacement request procedure 

The assigned channel replacement procedure permits the MS to propose channel replacement by sectored channels and 
channel classes where it can reliably decode downlink data and where it has a high probability of uplink communication 
according to the criteria in clause 18.3.4.9.9.5. 

An assigned channel replacement request may be made by the MS-MLE if one of the channel replacement criteria 
described in clause 18.3.4.9.9.5 is met, causing one or more sectored channels or channel classes to be selected by the 
MS-MLE. MS-MLE makes the request by sending a U-CHANNEL REQUEST PDU to the SwMI indicating a list of 
acceptable sectored channels and channel classes. 

The SwMI should respond to the request by sending the D-CHANNEL RESPONSE PDU, indicating acceptance or 
rejection of the request. If the response indicates that the request has been accepted, the D-CHANNEL RESPONSE 
PDU should be accompanied by a channel assignment which need not be to a sectored channel or channel class 
requested by the MS. 

The following conditions determine when the MS-MLE may transmit a U-CHANNEL REQUEST PDU: 

• the MS shall have been on the current assigned channel for time T372; and 

• the time T373 shall have elapsed after transmission of a previous U-CHANNEL REQUEST PDU; and 

• if a D-CHANNEL RESPONSE PDU received since the MS switched to the current channel contained the 
same value of "reason for the channel request" as that in the new U-CHANNEL REQUEST PDU, the 
MS-MLE shall not transmit the U-CHANNEL REQUEST PDU until the time "channel request retry delay" 
that was included in the D-CHANNEL RESPONSE PDU has elapsed since reception of that 
D-CHANNEL RESPONSE PDU. 

NOTE: The MS is not required to remember old "channel request retry delay" values after the current channel has 
been replaced. 
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1 8.3.4.9.1 1 Channel and sector advice procedure 

This clause applies to MSs which support the use of non-conforming channels and also applies to MSs which support 
data priority. 

When non-conforming channels exist on a cell, and the MS wishes to be able to use one (e.g. for the transmission or 
reception of packet data), it should advise the SwMI which sectored channels or concentric channel classes the MS can 
currently use. The advice is provided to the SwMI in a U-CHANNEL ADVICE or U-SECTOR ADVICE PDU. 

The SwMI should use the MS's advice on usable sectored channels and channel classes when assigning the MS to a 
channel. 

The method by which the MS-MLE is either requested or required by SNDCP to send a U-CHANNEL ADVICE or 
U-SECTOR ADVICE PDU with certain SNDCP PDUs is described in clause 18.3.5.3.1 item c). 

The MS-MLE may be requested or required to transmit a U-CHANNEL ADVICE PDU or U-SECTOR ADVICE PDU 
by the MS SNDCP, and the method of requesting or requiring is described in clause 18.3.5.1 item c). 

When the MS-MLE is requested by the MS SNDCP to transmit a U-CHANNEL ADVICE PDU or 
U-SECTOR ADVICE PDU, the MS-MLE should examine its ranked channel class list and its ranked sectored channel 
list for channel classes and channels which are radio usable, and determine its preferred channel classes and its 
preferred sectored channels. Then: 

• if the MS-MLE has not received an indication that the current cell supports non-conforming channels (see 
clause 18.3.4.9.1), or if no radio usable non-conforming channel class or sectored channel exists on the current 
cell (see clause 18.3.4.9.9.4), the MS-MLE shall transmit the SNDCP PDU without an attached 
U-CHANNEL ADVICE or U-SECTOR ADVICE PDU; or 

• if the MS-MLE has received an indication that the current cell supports non-conforming channels (see 
clause 18.3.4.9.1) and the MS-MLE wishes to use a non-conforming concentric channel, the MS-MLE should 
transmit the SNDCP PDU with a U-CHANNEL ADVICE PDU identifying at least the channel class that 
offers the best service of those channel classes that are currently radio usable (see clause 18.3.4.9.9.5 for the 
definition of service criteria); or 



• 



if the MS-MLE has received an indication that the current cell supports non-conforming channels (see 
clause 18.3.4.9.1) and the MS-MLE wishes to use a sectored channel, the MS-MLE should transmit the 
SNDCP PDU with a U-SECTOR ADVICE PDU indicating one or more radio usable channels which offer the 
best service of those sectored channels that are currently radio usable. 

When the MS-MLE is required by SNDCP to transmit a U-CHANNEL ADVICE PDU or U-SECTOR ADVICE PDU 
(this occurs when SNDCP requires the MS-MLE to send the data priority element), the MS-MLE should determine its 
preferred channel classes and its preferred sectored channels, if any exist. Then: 

• if the MS-MLE has not received an indication that the current cell supports non-conforming channels (see 
clause 18.3.4.9.1), or if the MS does not support the use of non-conforming channels, the MS-MLE shall 
transmit the SNDCP PDU with a U-CHANNEL ADVICE PDU and shall set the channel class identifier 
information element to "unspecified channel class"; or 

• if the MS-MLE has received an indication that the current cell supports non-conforming channels (see 
clause 18.3.4.9.1), but no radio usable non-conforming channel class or sectored channel exists on the current 
cell (see clause 18.3.4.9.9.4), and the MS supports the use of non-conforming channels, the MS-MLE shall 
transmit the SNDCP PDU with a U-CHANNEL ADVICE PDU and shall set the channel class identifier 
information element to "unspecified channel class" or "conforming channel class"; or 

• if the MS-MLE has received an indication that the current cell supports non-conforming concentric channels 
(see clause 18.3.4.9. l)on the current cell and the MS-MLE wishes to use a non-conforming concentric 
channel, the MS-MLE shall transmit the SNDCP PDU with a U-CHANNEL ADVICE PDU and should 
indicate at least the channel class that that offers the best service of those channel classes that are currently 
radio usable (see clause 18.3.4.9.9.5 for the definition of service criteria); or 

• if the MS-MLE has received an indication that the current cell supports non-conforming channels (see 
clause 18.3.4.9.1) and the MS-MLE wishes to use a sectored channel, the MS-MLE shall transmit the SNDCP 
PDU with a U-SECTOR ADVICE PDU indicating the relevant sectored channels. 
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The U-CHANNEL ADVICE and U-SECTOR ADVICE PDUs shall be transmitted attached to an SNDCP PDU using 
the method described in clause 18.3.5.3.1 item c). 

1 8.3.5 Data transfer sub-entity 

The services and primitives offered by the MLE are described in clause 17. 

18.3.5.1 Address handling 

The MLE manages all of the subscriber addresses (i.e. ITSIs and GTSIs) plus the management identity (i.e. TMI). 
These addresses and identities are described in EN 300 392-1 [6], clause 7. 

System subscriber Identities which are received or attached and detached by the MM entity should be transferred to 
MLE in an MLE-IDENTITIES request primitive. After being recorded locally and any lists amended, the list of 
currently valid short subscriber and management identities shall be transferred to the lower layers via the TLC-SAP in a 
TL-CONFIGURE request primitive as described in clause 18.3.5.1.2. 

Active group system subscriber identities which are received by the SS sub-entity shall be transferred to MLE in an 
MLE-IDENTITIES request primitive. After being recorded locally and any lists amended, the list of currently valid 
short subscriber and management identities shall be transferred to the lower layers via the TLC-SAP in a 
TL-CONFIGURE request primitive as described in clause 18.3.5.1.2. The MLE-IDENTITIES request primitive from 
the LCMC-SAP contains request to add and/or remove group identities 

Temporary group addresses allocated by SwMI or assumed by MS when setting up a group call, is informed to MLE by 
CMCE using the MLE-CONFIGURE request primitive. The MLE-CONFIGURE request primitive from the 
LCMC-SAP contains request to add and/or remove temporary group identities. The updated lists shall be transferred to 
the lower layers via the TLC-SAP in a TL-CONFIGURE request primitive as described in clause 18.3.5.1.2. 

18.3.5.1.1 Link addressing 

The MLE defines the MAIN ADDRESS and the ADDRESS TYPE parameters in all TL-CONNECT, TL-DATA, 
TL-DISCONNECT and TL-UNITDATA primitives issued to layer 2. The MAIN ADDRESS shall comprise of a valid 
SSI. 

For messages containing higher layer information, the MLE sets the MAIN ADDRESS SSI parameter to a valid SSI, as 
defined in EN 300 392-1 [6], clause 7. During migration, exchanged addresses shall be used, using the exchanged 
addresses issued by the MM in the MLE-IDENTITIES request primitive. 

If there is no vaHd SSI the MLE shall use an un-exchanged SSI (USSI) as defined in EN 300 392-1 [6], clause 7. An 
un-exchanged SSI may only be used for MM messages, refer clause 23.4.1.2.5. 

For messages from the MLE management entity, the MLE shall always add the SMI. The SMI is defined in 
EN 300 392-1 [6], clause 7. 

The MLE shall remove the MAIN ADDRESS and the ADDRESS TYPE parameters from all primitives received from 
layer 2. These parameters can be used for upward routing. In the service primitives to layer 3 MLE shall use ITSI or 
GTSI as appropriate. 

1 8.3.5.1 .2 Link addresses to be placed in layer 2 

In order to be able to filter, in layer 2, those messages received by the MS that are not applicable, layer 2 requires to be 
informed of all addresses that are valid for the MS. The MLE shall inform layer 2 by means of a TL-CONFIGURE 
request primitive the short subscriber and management identities that are valid for the MS. 

In the event that a SSI ceases to be valid, then the MLE shall inform layer 2 by means of a TL-CONFIGURE request 
primitive via the TLC-SAP. 
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1 8.3.5.1 .3 Layer 2 end point identifier 



The MLE may receive the layer 2 endpoint identifier in primitives exchanged with the layer 2. Endpoint identifier is 
assumed to be a local layer-to-layer matter, and is not defined in the present document. 

Endpoint identifiers uniquely identify radio resources, not fixed radio channels or timeslots. 

18.3.5.1.4 Subscriber class 

The MM informs the MLE of the MS subscriber class membership for a particular ITSI using an MLE-INFO request 
primitive. The MLE shall then use this value to determine if there is a match between the subscriber class being 
broadcasted by the SwMI and the subscriber class of the MS. The subscriber class is a bit mapped field which shall 
indicate which subscriber classes the MS is a member of The values are specified in clause 18.5. The subscriber class 
parameter may be allocated at subscription or registration. If the MS does not have a subscriber class from registration 
or subscription, the MS shall assume membership of all subscriber classes. The indication of whether there is a 
subscriber class match shall be indicated by MLE to the other layer 3 entities via the MLE-INFO indication service 
primitive. 

18.3.5.2 MLE connection handling 

An MLE connection is the logical association of the MLE peer entities in the MS/LS and the SwMI. The association is 
made by the mobile when it acquires a radio channel and camps on a cell. No explicit signalling is required in order to 
establish the connection. 

1 8.3.5.2.1 Data transfer states 

The following states shall exist in the data transfer entity. 

NOTE 1 : In the state machine the states themselves are provided for information, but conformance to the signalling 
specified for the output of the state machine is a requirement. 

NOTE 2: These states are the MLE state machine states, which are different to the service states presented in 
clause 17. 



a) Closed: 



the data transfer sub-entity shall enter state Closed after initial start up. This state shall also be entered 
after an MLE-CLOSE request primitive has been received from the MM entity indicating that there shall 
be no access to communication resources allowed. 



b) All Data: 



the data transfer sub-entity shall enter the state All Data if it has received an MLE-OPEN request 
primitive and has not subsequently received an MLE-CLOSE request primitive or MLE-BREAK 
indication primitive. 

c) Broken: 

the data transfer sub-entity enters this state upon receipt of an MLE-BREAK indication primitive from 
the attachment management sub-entity and indicates that the connection is temporarily broken. Upon 
receiving an MLE-RESUME indication primitive or an MLE-REOPEN indication primitive the data 
transfer sub -entity shall return to the all data state. 

18.3.5.3 Selection of LLC services 

1 8.3.5.3.1 Selection of LLC services via TLA-SAP 

Two types of data transfer are available at the layer 2 TLA-SAP: 

• acknowledged PDU transfer; and 

• unacknowledged PDU transfer. 
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The acknowledged service provides bidirectional data transfer, the unacknowledged service is unidirectional. 

The required service shall be interpreted from the information contained in the primitives from the higher entities 
according to the procedures specified below. 

The PDU priority, stealing permission and stealing repeats flag parameters shall be set by the sending higher layer 3 
entity and simply passed on to layer 2 by the MLE. The data priority of SN-DATA and SN-UNITDATA PDUs shall be 
set by the MS SNDCP and passed on to layer 2 by the MLE. In addition, for TL-CONNECT and TL-DISCONNECT 
request primitives which are issued by the MLE, the stealing permission parameter shall be set to "stealing not required" 
and the stealing repeats flag shall not be set. The PDU priority shall be equal to 3 for TL-CONNECT request primitive 
and 6 for TL-DISCONNECT request primitive. 

SNDCP uses both basic and advanced link services in the layer 2. The discrimination between the link types is based on 
the SN-PDU type and it is defined in clause 28. The following clauses define the SNDCP data transfer functionality for 
basic link and advanced link separately. 

a) Outgoing messages from MM and CMCE 

All outgoing messages shall be subject to the following handshake procedure with the LLC. 

MLE shall allocate a handle to all TL-DATA request primitives. Upon receipt of the TL-DATA request primitive the 
LLC may immediately acknowledge this with a TL-REPORT indication primitive containing the same handle as in the 
request, refer to clause 22.3.3.2.6. The handle shall be retained locally and used for routing subsequent MLE-REPORT 
indication primitives. The handle remains valid until a TL-DATA confirm primitive is received indicating that the PDU 
has been (successfully) transmitted, or, a TL-CANCEL request primitive is issued when the handle is deleted. 
TL-CANCEL request primitives may be issued until the receipt of the TL-REPORT indication primitive with reason 
"first complete transmission" or "failed transfer". 

On receipt of TL-REPORT indication primitive indicating successful transmission, the MLE shall issue MLE-REPORT 
indication primitive to the SAP which sent the original TL-DATA request primitive to inform the higher layer 3 entity 
that the PDU has been successfully transmitted by layer 2. 

On receipt of an MLE-UNITDATA request primitive, the data transfer sub-entity shall append an MLE PDU header 
indicating the originating SAP using the protocol discriminator field. The PDU header values are defined in 
clause 18.4.2. The data transfer sub-entity shall determine the length of the PDU and pass that information to the LLC 
as a primitive parameter. 

The underlying service selected shall be the basic link or advanced link and determined according to the layer 2 service 
parameter in the MLE-UNITDATA request primitive. The MLE shall set up an advanced link when needed by MM 
and/or CMCE. 

If the layer 2 service parameter has the value "acknowledged request" then the MLE UNITDATA PDU shall be 
transferred to the LLC in a TL-DATA request primitive. 

If the layer 2 service parameter has the value "acknowledged response" then the MLE UNITDATA PDU shall be 
transferred to the LLC in a TL-DATA response primitive. 

If the layer 2 service parameter has the value "unacknowledged" then the MLE UNITDATA PDU shall be transferred to 
the LLC in a TL-UNITDATA request primitive. 

On receipt of an MLE-CANCEL request primitive from the CMCE or MM SAP, the data transfer sub-entity shall issue 
a TL-CANCEL request primitive to the TLA-SAP. Once the TL-CANCEL request primitive has been issued any 
references to the handle in the MLE shall be deleted. 

The basic link shall be used for all MM signalling and CMCE call related signalling. The FCS flag may be set to 
indicate the use of the optional FCS for basic link transfer. Whether or not the optional FCS is selected for basic link 
transfer is not defined in the present document. 

The advanced link may also be used for transfer of long SDUs. This may be required for the short data service which 
can send up to 2 047 bits of data or for transfer of SS information. A separate or the same advanced link can be used by 
MM and/or CMCE to that used by SNDCP for packet data transfer. 

NOTE 1: CMCE SDS and SS information may be up-linked to the BS and down-linked to the MS on an existing 
advanced link which was negotiated on behalf of packet data entity at some earlier time. 
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NOTE 2: The MLE may negotiate an advanced link specifically for the up-linking of CMCE SDS and SS 
signalling. 

NOTE 3: The BS may negotiate an advanced link specifically for the down-linking of CMCE SDS and SS 
signalling. 

NOTE 4: The MLE should take into account the QoS requirements of other advanced link users when selecting a 
particular advanced link for the up-linking of CMCE SDS and SS signalling. The MLE should, if 
possible, select an advanced link adapted to the transport of background class data. 

b) Incoming messages to MM and CMCE 

On receipt of a TL-UNITDATA indication primitive, the data transfer sub-entity shall remove and analyse the MLE 
PDU header and address. The PDU header indicates the destination SAP. The address may indicate that this is a 
network broadcast message. The data contained in the TL-UNITDATA indication primitive shall then be routed to the 
correct SAP or sub-entity as an MLE-UNITDATA indication primitive. Network broadcast D-NWRK-BROADCAST 
PDUs shall be routed by the data transfer sub-entity to the network broadcast sub-entity. Late entry information from 
the D-MLE-SYNC PDU shall be routed to the CMCE SAP. 

On receipt of a TL-DATA indication primitive, the data transfer sub-entity shall remove and analyse the MLE PDU 
header. The PDU header indicates the destination SAP. The data contained in the TL-DATA indication primitive shall 
then be routed to the correct SAP or sub-entity as an MLE-UNITDATA-indication primitive. 

On receipt of a TL-DATA confirm primitive, the MLE shall issue an MLE-REPORT indication primitive to indicate 
successful transmission of the PDU transmitted as a result of the previous TL-DATA request primitive as indicated by 
the "handle to the request" parameter. The data transfer sub-entity shall then remove and analyse the MLE PDU header. 
The PDU header indicates the destination SAP. The data contained in the TL-DATA indication primitive shall then be 
routed to the correct SAP or sub-entity as an MLE-UNITDATA indication primitive. 

c) Outgoing basic link messages from SNDCP 

The data transfer sub entity shall reject service requests when in state closed. When in the broken state, messages shall 
not be passed by the MLE. 

All outgoing messages shall be subject to the following handshake procedure with the LLC. 

MLE shall allocate a handle to all TL-DATA and TL-UNITDATA request primitives. Upon receipt of the TL-DATA, 
or TL-UNITDATA request primitive the LLC may immediately acknowledge this with a TL-REPORT indication 
primitive containing the handle, refer to clause 22.3.3.2.6. The handle shall be retained locally and used for routing 
subsequent MLE-REPORT indication primitives. 

Where the outgoing message has resulted in the MLE requesting an unacknowledged service from the LLC, the handle 
remains valid until a further TL-REPORT indication primitive is received indicating that the PDU has been transmitted, 
or, a TL-CANCEL request primitive is issued when the handle is deleted. 

Where the outgoing message has resulted in the MLE requesting an acknowledged service from the LLC, the handle 
remains valid until a TL-DATA confirm primitive is received indicating that the PDU has been successfully 
transmitted, or, a TL-CANCEL request primitive is issued when the handle is deleted. TL-CANCEL request primitives 
may be issued until the receipt of the second TL-REPORT indication primitive, even though the handle remains valid in 
the latter case. 

On receipt of a TL-DATA confirm primitive, the MLE shall issue an MLE-REPORT indication primitive indicating 
successful transmission of the PDU transmitted as a result of the previous TL-DATA request primitive on that endpoint 
identifier and link identifier. If the TL-DATA confirm primitive contains an SDU, this shall then be passed to the higher 
layers using MLE-UNITDATA indication primitive. 

On receipt of an MLE-UNITDATA request primitive, the data transfer sub entity shall determine the state of the 
MLE data priority flag parameter and the state of the channel advice request flag parameter. Then: 

• If MLE data priority signalling is not required by the MLE data priority flag parameter, and channel advice is 
not requested by the channel advice request flag parameter, the data transfer sub entity shall append an MLE 
PDU header indicating the originating SAP using the protocol discriminator field. The protocol discriminator 
values are defined in clause 18.5.21. 
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• If MLE data priority signalling is required and channel advice is not requested, the MS-MLE is required to 
transmit a U-CHANNEL ADVICE PDU. The data transfer sub entity shall insert the SN-PDU into the SDU 
element of a U-CHANNEL ADVICE PDU (see clause 18.3.4.9.II), shall include in the PDU the value of the 
data priority parameter from the MLE-UNITDATA request primitive in the PDU, and shall append an MLE 
PDU header indicating the originating SAP using the protocol discriminator field. 

• If MLE data priority signalling is required and channel advice is requested, the MS-MLE is required to 
transmit a U-CHANNEL ADVICE PDU or U-SECTOR ADVICE PDU. The data transfer sub entity shall 
insert the SN-PDU into the SDU element of a U-CHANNEL ADVICE PDU or a U-SECTOR ADVICE PDU 
(see clause 18. 3.4. 9. 11), shall include in the PDU the value of the data priority parameter from the 
MLE-UNITDATA request primitive in the PDU, and shall append an MLE PDU header indicating the 
originating SAP using the protocol discriminator field. 

• If MLE data priority signalling is not required and channel advice is requested, the MS-MLE is requested to 
transmit a U-CHANNEL ADVICE PDU or U-SECTOR ADVICE PDU if the MS-MLE has received an 
indication that the current cell supports non-conforming channels (see clause 18.3.4.9.1). The data transfer sub 
entity may insert the SN-PDU into the SDU element of a U-CHANNEL ADVICE PDU or 

U-SECTOR ADVICE PDU (see clause 18.3.4.9.1 1), In this case, the MS-MLE shall not send a data priority 
element with the MLE PDU. The MS-MLE shall append an MLE PDU header indicating the originating SAP 
using the protocol discriminator field. 

The data transfer sub entity shall determine the length of the PDU and pass that information to the LLC as a primitive 
parameter. 

If the layer 2 service parameter has the value "acknowledged request" then the MLE UNITDATA PDU shall be 
transferred to the LLC in a TL-DATA request primitive. 

If the layer 2 service parameter has the value "acknowledged response" then the MLE UNITDATA PDU shall be 
transferred to the LLC in a TL-DATA response primitive. 

If the layer 2 service parameter has the value "unacknowledged" then the MLE UNITDATA PDU shall be transferred to 
the LLC in a TL-UNITDATA request primitive. 

Whether or not the optional PCS is selected in basic link transfer is not defined in the present document. 

The SDU shall be sent to the TLA SAP in a TL-DATA request primitive unless an unacknowledged data transfer is 
specifically requested, in which case the SDU shall be sent in a TL-UNITDATA request primitive. 

d) Incoming basic link messages to SNDCP 

On receipt of a TL-UNITDATA indication primitive, the data transfer sub-entity shall remove and analyse the MLE 
PDU header and address. The PDU header indicates the destination SAP. The data contained in the TL-UNITDATA 
indication primitive shall then be routed to the correct SAP or sub-entity as an MLE-UNITDATA indication primitive. 

On receipt of a TL-DATA indication primitive, the data transfer sub-entity shall remove and analyse the MLE PDU 
header. The PDU header indicates the destination SAP. The data contained in the TL-DATA indication primitive shall 
then be routed to the correct SAP or sub-entity as an MLE-UNITDATA indication primitive. 

On receipt of a TL-DATA confirm primitive, the MLE shall issue an MLE-REPORT indication primitive to indicate 
successful transmission of the PDU transmitted as a result of the previous TL-DATA request primitive on that endpoint 
identifier and link identifier. The data transfer sub-entity shall then remove and analyse the MLE PDU header. The 
PDU header indicates the destination SAP. The data contained in the TL-DATA confirm primitive shall then be routed 
to the correct SAP or sub-entity as an MLE indication primitive, as determined by the MLE PDU header. MLE service 
user PDUs are routed to the appropriate SAP in MLE-UNITDATA indication primitives. 

e) Outgoing advanced link messages from SNDCP 

The data transfer sub entity shall reject service requests when in state closed. When in the broken state, messages shall 
not be passed by the MLE. 

All outgoing messages shall be subject to the following handshake procedure with the LLC. 
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Upon receipt of the TL-CONNECT, TL-DIS CONNECT, TL-DATA, TL-RECONNECT or TL-UNITDATA request 
primitive the LLC will immediately acknowledge this with a TL-REPORT indication primitive containing the handle. 
The handle shall be retained locally and used for routing subsequent REPORT indication primitives. Where the 
outgoing message has resulted in the MLE requesting an unacknowledged service from the LLC, the handle remains 
valid until a further TL-REPORT indication primitive is received indicating that the PDU has been transmitted, or, a 
TL-CANCEL request primitive is issued when the handle is deleted. Where the outgoing message has resulted in the 
MLE requesting an acknowledged service from the LLC, the handle remains valid until a TL-DATA confirm primitive 
is received indicating that the PDU has been successfully transmitted, or a TL-CANCEL request primitive is issued 
when the handle is deleted. TL-CANCEL request primitives may be issued until the receipt of the second TL-REPORT 
indication primitive, even though the handle remains valid in the latter case. 

On receipt of a TL-DATA confirm primitive, the MLE shall issue an MLE-REPORT indication primitive indicating 
successful transmission of the PDU transmitted as a result of the previous TL-DATA request primitive on that endpoint 
identifier and link identifier. If the TL-DATA confirm primitive contains an SDU, this shall then be passed to the higher 
layers using MLE-UNITDATA indication primitive. 

The SNDCP shall use the advanced link to ensure reliable transmission of long packets (i.e. longer than about 3 TDMA 
slots worth of data). The MS shall only attempt to set up an advanced link if both the SwMI supports SNDCP operation 
and if the advanced link is supported by the SwMI on this cell. This information is indicated in the BS service details 
element broadcast as part of the D-MLE SYSINFO and D-MLE SYSINFO-Q PDUs. If either SNDCP or the advanced 
link is not supported by the SwMI on this cell then the LTPD-SAP shall be closed (MLE-Close indication primitive 
issued). 

The quality of service parameters passed down by SNDCP using MLE-CONNECT request primitive shall be used by 
the MS in negotiating the advanced link service during set up. How the Quality of Service parameter in the 
MLE-CONNECT request primitive maps onto the advanced link quality of service selection in the AL-SETUP PDU is 
not defined by the present document. 

On receipt of a MLE-CONNECT request primitive from SNDCP, the data transfer subentity shall issue a 
TL-CONNECT request primitive to the TLA-S AP. Upon receipt of the corresponding TL-CONNECT confirm 
primitive, the data transfer subentity shall issue a MLE-CONNECT confirm primitive to SNDCP. 

On receipt of a MLE-DISCONNECT request primitive from SNDCP, the data transfer subentity shall issue a 
TL-DISCONNECT request primitive to the TLA-S AP. Upon receipt of the corresponding TL-DISCONNECT confirm 
primitive, the data transfer subentity shall issue a MLE-DISCONNECT indication primitive to SNDCP. 

On receipt of a MLE-RECONNECT request primitive from SNDCP, the data transfer subentity shall issue a 
TL-RECONNECT request primitive to the TLA-S AP. Upon receipt of the corresponding TL-RECONNECT confirm 
primitive, the data transfer subentity shall issue a MLE-RECONNECT indication primitive to SNDCP. 

On receipt of an MLE-UNITDATA request primitive, the data transfer sub entity shall append an MLE PDU header 
indicating the originating SAP using the protocol discriminator field. The protocol discriminator values are defined in 
clause 18. The data transfer sub entity shall determine the length of the PDU and pass that information to the LLC as a 
primitive parameter. 

If the layer 2 service parameter has the value "acknowledged request" then the MLE UNITDATA PDU shall be 
transferred to the LLC in a TL-DATA request primitive. 

For messages using the advanced link, the layer 2 service parameter shall not be set to "acknowledged response". 

If the layer 2 service parameter has the value "unacknowledged" then the MLE UNITDATA PDU shall be transferred to 
the LLC in a TL-UNITDATA request primitive. 

On receipt of a MLE-RELEASE request primitive from SNDCP, the data transfer subentity shall issue a TL-RELEASE 
request primitive to the TLA-SAP. All references to the advanced link in question shall be deleted. 

f) Incoming advanced link messages to SNDCP 

On receipt of a TL-CONNECT indication primitive, the data transfer sub entity shall issue MLE-CONNECT indication 
primitive to the SNDCP. 

On receipt of a TL-CONNECT confirm primitive, the data transfer sub entity shall issue MLE-CONNECT confirm 
primitive to the SNDCP. 
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On receipt of a TL-RECONNECT confirm primitive, the data transfer sub entity shall issue MLE-RECONNECT 
confirm primitive to the SNDCP. 

On receipt of a TL-DISCONNECT indication primitive, the data transfer sub entity shall issue MLE-DIS CONNECT 
indication primitive to the SNDCP if the TL-DISCONNECT indication primitive refers to an established advanced link. 
This can be established by using the link identifier. If it does refer to an established advanced link, any local reference 
to that advanced link shall be deleted. 

On receipt of a TL-DISCONNECT confirm primitive, the data transfer sub entity shall issue MLE-DISCONNECT 
indication primitive to the SNDCP. 

On receipt of a TL-UNITDATA indication primitive, the data transfer sub entity shall remove and analyse the MLE 
PDU header and address. The PDU header indicates the destination SAP. The data contained in the TL-UNITDATA 
indication primitive shall then be routed to the correct SAP or sub entity as an MLE-UNITDATA indication primitive. 

On receipt of a TL-DATA indication primitive, the data transfer sub entity shall remove and analyse the MLE PDU 
header. The PDU header indicates the destination SAP. The data contained in the TL-DATA indication primitive shall 
then be routed to the correct SAP or sub entity as an MLE-UNITDATA indication primitive. 

On receipt of a TL-DATA confirm primitive, the MLE shall issue an MLE-REPORT indication primitive to indicate 
successful transmission of the PDU transmitted as a result of the previous TL-DATA request primitive on that endpoint 
identifier and link identifier. The data transfer sub entity shall then remove and analyse the MLE PDU header. The PDU 
header indicates the destination SAP. The data contained in the TL-DATA confirm primitive shall then be routed to the 
correct SAP or sub entity as an MLE indication primitive, as determined by the MLE PDU header. MLE service user 
PDUs are routed to the PDP-SAP in MLE-UNITDATA indication primitives. 

1 8.3.5.3.2 Selection of LLC services via TLB-SAP 

There are no services available at the TLB-SAP in the MS. 

Data received via the TLB-SAP is routed to the network broadcast sub-entity and is dealt with in clause 18.3.6. 

1 8.3.5.3.3 Selection of LLC services via TLC-SAP 

a) Locally generated TL-CONFIGURE request primitives 

The data transfer sub-entity shall supply TL-CONFIGURE request primitives to the TLC-SAP to inform the lower 
layers of the state of any MM signalling, SNDCP signalling or circuit mode calls in progress. The 
MLE activity indicator parameter in the TL-CONFIGURE request primitive allows the lower layers to decide when to 
apply energy economy. 

NOTE 1: It is possible to apply an energy economy scheme that has been notified to, and agreed by, the SwMI. 

The TL-CONFIGURE request primitive shall be sent with the MLE-Activity indicator parameter set to "stay alive" 
when there is any explicit or implicit connection active. The TL-CONFIGURE request primitive may only be sent with 
the MLE activity indicator parameter set to "sleep permitted" when there is no MM, SNDCP or CMCE e.g. circuit mode 
call activity. 

MM indicates its activity by an MLE-ACTIVITY request primitive with sleep mode value "stay alive", and its 
non-activity with sleep mode value "sleep permitted" as defined in clause 16.3.1.3.4. 

SNDCP indicates its activity by an MLE-ACTIVITY request primitive with sleep mode set to "stay alive", and its 
non-activity with sleep mode value "sleep permitted", see clauses 28.2.4.4, 28.2.4.6, 28.2.4.7, 28.2.4.8 and 28.2.5. 

CMCE indicates its activity by an MLE-ACTIVITY request primitive with call state value "group call with transmit 
permission", "group call without transmit permission", "individual call with transmit permission" and "individual call 
without transmit permission", and its non-activity with call state value "idle", see clauses 14.2.7.7.0 and 14.4.2. 

NOTE 2: The MLE-ACTIVITY request primitive with call state values "group call without transmit permission" or 
"individual call without transmit permission" are sent at the beginning of a call set-up and the CMCE 
activity covers also the call set-up period before the voice communication is possible. 

MLE shall combine activity indications from upper layers and inform using TL-CONFIGURE request primitive MLE 
activity indicator parameter, when sleeping is permitted. 
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Advanced link, on its own is active during set up, reset, reconnection and disconnection phases, see clause 22.3.6. 

b) Locally received TL-SELECT indication primitives 

Where the MLE receives a TL-SELECT indication primitive via the TLC-SAP indicating that the MAC has been 
instructed to change channels and no response is required, this is dealt with in clause 18.3.4.3. 

The only case where the MLE is required to respond to a channel change TL-SELECT indication primitive is in the 
case of cell change in announced type 1 cell reselection. In this case the MLE shall respond with TL-SELECT response 
primitive containing a parameter which gives the frequency of the main carrier on the new cell. 

c) Outgoing messages from MM 

These are generally routed via the attachment management sub-entity (see clause 18.3.4). 

There are two exceptions to this. 

The first is the MLE-IDENTITIES request primitive which contains the valid ISSI(s) and attached/detached GSSIs. The 
procedures for dealing with this are described in clause 18.3.5.1. 

The second is the MLE-INFO request primitive which after the local recording of the subscriber class within the data 
transfer sub-entity is transferred further to the lower layers in a TL-CONFIGURE request primitive. 

d) Incoming messages to MM 

These are routed via the attachment management sub-entity (see clause 18.3.4). 

e) Outgoing messages from SNDCP 

On receipt of a MLE-CONFIGURE request primitive, the MLE shall pass on relevant information contained in its 
parameters to layer 2 using TL-CONFIGURE request primitive. 

f) Incoming messages to SNDCP 

There are no messages routed from the TLC-SAP to SNDCP. 

g) Outgoing messages from CMCE 

On receipt of an MLE-CONFIGURE request primitive, MLE shall pass on the information contained in its parameters 
to layer 2 using TL-CONFIGURE request primitive. 

On receipt of an MLE-IDENTITIES request primitive, MLE shall pass on the information contained in its parameters to 
layer 2 using TL-CONFIGURE request primitive. 

h) Incoming messages to CMCE 

There are no CMCE primitives received on the TLC-SAP. 

1 8.3.5.4 Routing of local control information 

On receipt of an MLE-OPEN request primitive from the MM SAP, the data transfer sub-entity shall issue an 
MLE-OPEN indication primitive to the CMCE and SNDCP SAPs. The data transfer sub-entity shall then open the 
S APs and shall permit the transfer of data between layers. If the MLE-OPEN request primitive is received whilst the 
data transfer sub-entity is in state closed then the data transfer sub-entity shall enter state all data. In all other states it 
shall remain in that state. 

On receipt of an MLE-CLOSE request primitive from the MM SAP the data transfer sub-entity shall relay this as an 
MLE-CLOSE indication primitive to the CMCE and SNDCP SAPs. The data transfer sub-entity shall then close the 
SAPs and shall not permit the transfer of data between layers. The data transfer sub-entity shall enter state closed, and 
shall remain in that state until it receives an MLE-OPEN indication primitive. 
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On receipt of an MLE-DISABLE request primitive from the MM SAP, the data transfer sub-entity shall issue an 
MLE-DISABLE indication primitive to the CMCE SAP and the SNDCP SAP. 

On receipt of an MLE-ENABLE request primitive from the MM SAP, the data transfer sub-entity shall issue an 
MLE-ENABLE indication primitive to the CMCE SAP and the SNDCP SAP. 

On receipt of an MLE-BREAK indication primitive from the attachment management sub-entity, the data transfer 
sub-entity shall relay this MLE-BREAK indication primitive to the CMCE and SNDCP SAPs. The data transfer 
sub-entity shall enter state broken. During a temporary link break data may be buffered in the data transfer sub-entity. 

On receipt of an MLE-RESUME indication primitive from the attachment management sub-entity, the data transfer 
sub-entity shall relay this MLE-RESUME indication primitive to the CMCE and SNDCP SAPs. The data transfer 
sub-entity shall return to its previous state. Any data buffered in the data transfer sub-entity during the temporary link 
break should now be (re)submitted for transmission. 

On receipt of an MLE-REOPEN indication primitive from the attachment management sub-entity, the data transfer 
sub-entity shall relay this MLE-REOPEN indication primitive to the CMCE SAP. The data transfer sub-entity shall 
enter state idle. Any data buffered in the data transfer sub-entity during the temporary link break should now be 
discarded. 

On receipt of an MLE-BUSY request primitive from the MM SAP, the data transfer sub-entity shall issue a 
MLE-BUSY indication primitive to the CMCE and SNDCP SAPs. 

On receipt of an MLE-IDLE request primitive from the MM SAP, the data transfer sub-entity shall issue a MLE-IDLE 
indication primitive to the CMCE and SNDCP SAPs. 

On receipt of a TL-REPORT indication primitive from LLC layer containing the reason "channel change", 
"transmission stopped", "reception stopped" the data transfer sub-entity shall relay it in an MLE-CONFIGURE 
indication primitive to the entity which is using the radio resource as indicated by the endpoint identifier parameter. 

NOTE: The channel change is also conveyed in MLE-DATA and MLE-UNITDATA indication primitives. 

On receipt of a TL-CONFIGURE indication primitive with "loss of radio resource" from lower layers the data transfer 
sub-entity shall relay it in an MLE-CONFIGURE indication primitive into the service user(s) who is using this radio 
resource as indicated by the endpoint identifier parameter. 

1 8.3.6 Network broadcast sub-entity 
18.3.6.1 Summary 

The system broadcast function broadcasts system information from the SwMI to all MSs. 
There are two formats for this system information: 

• immediate system information; 

• network broadcast system information. 

The immediate system information is supplied to layer 2 in the SwMI and broadcast on the BNCH and BSCH as 
defined in clause 9. The exact method by which the information is supplied to layer 2 is outside the scope of the present 
document. At the MS the MLE-PDU shall be received by the network broadcast sub-entity as TL-SYNC indication and 
TL-SYSINFO indication primitives via the TLB-SAP. 

The network broadcast system information and late entry information is supplied to layer 2 in the SwMI and broadcast 
as requested. The exact method by which the information is supplied to layer 2 is outside the scope of the present 
document. At the MS the MLE-PDUs shall be received by the network broadcast sub-entity as a 
D-NWRK-BROADCAST PDU and (if supported) a D-NWRK-BROADCAST EXTENSION PDU with a 
TL-UNITDATA indication primitive via the TLA-SAP and data transfer sub-entity. The MLE is able to route the 
network broadcast system information to the network broadcast sub-entity by virtue of the PDU headers it arrives with, 
and the late entry information to CMCE-S AP by virtue of the PDU header it arrives with. 

The SwMI shall indicate whether or not it supports transmission of the D-NWRK-BROADCAST PDU using the 
"neighbour cell broadcast" element which is transmitted as part of the D-MLE-SYNC PDU. 
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System broadcast information can be received whilst the MS is scanning or is camped on a cell. The MS-MLE shall 
ensure that system broadcast information received whilst scanning is applied to the correct cell. 

An MS may also prompt the SwMI to transmit the network broadcast system information by using the neighbour cell 
enquiry procedure as described in clause 18.3.6.5. 

18.3.6.2 System information 

The system information is a series of messages that are broadcast at regular intervals from the SwMI to the MS-MLEs. 
The immediate system information contains the following information: 

MNC; 

MCC; 

LA Code (LAC); 

subscriber class; 

cell service level; and 

late entry information availability. 

The network broadcast system information in the D-NWRK-BROADCAST PDUs contain a combination of the 
following information: 

• frequencies of adjacent cells for cell selection and reselection; 

• parameters for roaming (measurement levels, intervals). 

The network broadcast system information in the D-NWRK-BROADCAST EXTENSION PDUs contain a combination 
of the following information: 

the modulation modes and bandwidths of channel classes available on the serving cell; 

frequencies, modulation modes and bandwidths of sectored channels available on the serving cell; 

the modulation modes and bandwidths of channel classes available on neighbour cells; 

frequencies, modulation modes and bandwidths of sectored channels available on neighbour cells; 

parameters for channel quality assessment (measurement levels). 

This information should be used by the MSs to guide the cell selection and assigned channel replacement request 
procedures. 

1 8.3.6.3 Message formats for system information 

System information messages shall be constructed according to the rules described in clause 18.4. Each network 
broadcast system information may contain any combination of information elements. 

1 8.3.6.4 Network broadcast procedures 

On receiving a TL-SYNC indication primitive, a TL-SYSINFO indication primitive or a TL-SYSINFO-Q indication 
primitive via the TLB-SAP, the network broadcast sub-entity shall analyse the contents. The information contained 
within shall either be passed to attachment management, e.g. to update cell rankings, or, in the case of a new subscriber 
class bit map, shall be passed to the data transfer sub-entity. 
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1 8.3.6.5 Neighbour cell enquiry procedure 

An MS may prompt the SwMI to transmit the D-NWRK-BROADCAST PDU and the 

D-NWRK-BROADCAST EXTENSION PDU by sending a U-PREPARE PDU to the SwMI. The U-PREPARE PDU 
shall not contain an SDU. The U-PREPARE PDU shall contain the cell identifier element which shall be set to 
"OOOOO2" and which shall indicate to the SwMI that the MS is requesting transmission of the D-NWRK-BROADCAST 
PDU and (if supported) the D-NWRK-BROADCAST-EXTENSION PDU. 

NOTE: The MS may request transmission of the D-NWRK-BROADCAST PDU and 

D-NWRK-BROADCAST EXTENSION PDU because it has yet not received the neighbour cell or 
channel class or sectored channel information and the MS needs this in order to initiate cell reselection or 
assigned channel replacement request procedures. This may occur if the current serving cell or assigned 
channel signal level is falling and the MS cannot wait for the normal D-NWRK-BROADCAST PDU or 
D-NWRK-BROADCAST EXTENSION PDU broadcast to be sent. 

An MS may not receive the normal D-NWRK-BROADCAST PDU broadcast, for example, as a result of 
being in energy economy and it is sleeping while the D-NWRK-BROADCAST PDU is being transmitted 
by the SwMI. 

MLE shall send the U-PREPARE PDU by issuing a TL-DATA request primitive to layer 2 with the primitive 
parameters set as follows: 

• PDU priority shall be set to 3; 

• stealing permission shall be set to "steal immediately"; 

• the stealing repeats flag shall not be set. 

MLE shall start timer T370 and, if supported, T371, and shall await the response from the SwMI. The SwMI shall 

respond by transmitting the D-NWRK-BROADCAST PDU and, if supported, the 

D-NWRK-BROADCAST EXTENSION PDU, which may be individually addressed to the MS using the layer 2 

acknowledged service or may be sent unacknowledged to a group address or to the broadcast address ("all ones" 

address). 

On reception of the D-NWRK-BROADCAST PDU, the MLE shall reset timer T370. If timer T370, expires the MS 
shall assume that the cell enquiry service has failed and shall wait for the SwMI to send the normal 
D-NWRK-BROADCAST PDU broadcast. On reception of the D-NWRK-BROADCAST EXTENSION PDU, the MLE 
shall reset timer T37L If timer T371 expires the MS shall assume that the channel enquiry service has failed or is not 
supported and shall wait for the SwMI to send the normal D-NWRK-BROADCAST EXTENSION PDU. The SwMI 
may also respond to the U-PREPARE PDU with a D -PREP ARE-FAIL PDU which has the "Fail cause" element set 
equal to "Neighbour cell enquiry not available". 

The SwMI shall indicate whether or not the neighbour cell enquiry service is supported using the "neighbour cell 
broadcast" element which is transmitted as part of the D-MLE-SYNC PDU. If the service is not supported, the MS shall 
not attempt to send the U-PREPARE PDU with the cell identifier set to "OOOOO2". 



18.3.7 Management sub-entity 



The management sub-entity shall be responsible for communication of management information between the MS and 
the SwMI. MLE PDUs to and from the management sub-entity shall have a protocol discriminator set to "IIO2". The 
PDUs shall be transferred between the MS and the SwMI using the TMI as the source address on the uplink and as the 
destination address on the downlink. 

No TETRA management PDUs are defined in the present document. 



18.4 PDU descriptions 



The following PDU descriptions contain a mapping of the information elements into an MLE PDU specifying the 
length of the element, the type of the element and whether the element is mandatory, conditional or optional. The 
contents of the information elements themselves are further detailed in clause 18.5. 
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The information contained in the PDU description tables corresponds to the following key: 

• Length: length of the element in bits; 

• Type: element type 1 or 2 as defined below; 

• C/O/M: conditional/optional/mandatory information in the PDU; 

• Remark: comment. 

18.4.1 Data transfer PDUs at the TLA-SAP 

1 8.4.1 .1 Protocol discriminator 

The contents of an MLE PDU sent and received at the TLA-SAP shall be determined by a 3 bit protocol discriminator. 
The discriminator shall be the first element field in the MLE PDU. 

The protocol discriminator shall determine the MLE user SAP endpoint, i.e. it is used as routing information within the 
MLE data transfer sub-entity. 

If the protocol discriminator indicates CMCE, MM, or SNDCP, then the MLE shall remove the protocol discriminator 
and route the SDU to the relevant upper layer 3 protocol entity. 

If the protocol discriminator indicates TETRA management entity, then the MLE shall remove the protocol 
discriminator and route the SDU to the TETRA management functional entity within the MLE protocol entity. 

If the protocol discriminator indicates MLE, then the MLE shall remove the protocol discriminator and process the 
remainder of the PDU according to the MLE protocol. 

18.4.1.2 PDU type 

When the protocol discriminator indicates the MLE protocol, a "PDU type" element shall follow which shall indicate 
the particular MLE protocol PDU type. 

1 8.4.1 .3 MLE service user PDUs 

PDUs which have the protocol discriminator equal to one of the following: MM, SNDCP, CMCE or TETRA 
Management Entity shall be defined as in table 18.1. 

Table 18.1 : MLE service PDU layout 



Information element 


Length 


Value 


Remark 


Protocol discriminator 


3 




See clause 18.5.21 for element definition 


SDU 


Variable 




IVIM, CMCE, SNDCP or Management Entity SDU 



The SDUs sent/received at the LMM-SAP, LTPD-SAP, LCMC-SAP and to/from the management entity shall be 
transparent to the MLE. The MLE shall simply route these SDUs according to the protocol discriminator. 

1 8.4.1 .4 MLE protocol PDUs 

MLE PDUs which have the protocol discriminator MLE protocol shall comprise both cell change PDUs and network 
broadcast PDUs. 

Refer to annex E for description of the general format of the MLE protocol PDU. 
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18.4.1.4.1 



D-NWRK-BROADCAST 



Message: 



Response to: 
Response expected: 
Short description: 



D-NWRK-BROADCAST 



-/U-PREPARE 



Upon receipt from the SwMI, the message shall inform the MS-MLE about 
parameters for the serving cell and parameters for one or more neighbour cells. 

Table 18.2: D-NWRK-BROADCAST PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


D-NWRK-BROADCAST 


Cell re-select parameters 


16 


1 


M 




Cell service level 


2 


1 


M 




TETRA network time 


48 


2 







Number of neighbour cells 


3 


2 





See note 1 


Neighbour cell information 








See note 2 


NOTE 1 : If present, the element shall indicate how many "Neighbour cell information" elements 
follow. If not present, no neighbour cell information shall follow. 

NOTE 2: The element definition is contained in clause 18.5 which gives the type and length for each 
sub-element which is included in this element. The element shall be repeated as many 
times as indicated by the "Number of neighbour cells" element. There shall be no P-bIt 
preceding each neighbour cell information element which is carried by this PDU. 
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18.4.1.4.1a 



D-NWRK-BROADCAST-EXTENSION 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



D-NWRK-BROADCAST EXTENSION 



-/U-PREPARE 



Upon receipt from the SwMI, the message shall inform the MS-MLE about 
parameters for the serving cell and parameters for one or more neighbour cells. 

Table 18.3: D-NWRK-BROADCAST-EXTENSION PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


D-NWRK-BROADCAST-EXTENSION 


Number of channel classes (for serving 
cell) 


4 


2 







Channel class 


variable 






See note 1 


Number of neighbour cell channel classes 


5 


2 







Neighbour cell channel class 


variable 






See note 2 


Number of sectored channel details (for 
serving cell) 


5 


2 







Sectored channel detail 


variable 






See note 3 


Number of neighbour cell sectored 
channel details 


6 


2 







Neighbour cell sectored channel detail 


variable 






See note 4 


Reserved 


32 


2 





See note 5 


Reserved 


32 


2 





See note 5 


NOTE 1 : The element definition is contained in clause 18.5.5b which gives the type and length for each 
sub-element which is included in this element. The element shall be repeated as many times as 
indicated by the "Number of channel classes (for serving cell)" element. 

NOTE 2: The element definition is contained in clause 18.5.16a which gives the type and length for each 
sub-element which is included in this element. The element shall be repeated as many times as 
indicated by the "Number of neighbour cell channel classes" element. 

NOTE 3: The element definition is contained in clause 18.5.21b which gives the type and length for each 
sub-element which is included in this element. The element shall be repeated as many times as 
indicated by the "Number of sectored channel details (for serving cell)" element. 

NOTE 4: The element definition is contained in clause 18.5.17a which gives the type and length for each 
sub-element which is included in this element. The element shall be repeated as many times as 
indicated by the "Number of neighbour cell sectored channel details" element. 

NOTE 5: Shall not be used in the present document. 
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18.4.1.4.2 



D-NEW-CELL 



Message: 



Response to: 
Response expected: 
Short description: 



D-NEW-CELL 



U-PREPARE 



Upon receipt from the SwMI the message shall inform the MS-MLE that it can 
select a new cell as previously indicated in the U-PREPARE PDU. 

Table 18.4: D-NEW-CELL PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


D-NEW-CELL 


Channel command valid 


2 


1 


M 




SDU 








See note 


NOTE: The SDU may carry an MM registration PDU which is used to forward register to a new cell 
during announced type 1 cell reselection or a D-OTAR CCK PROVIDE PDU which is used 
to identify the current CCK, it may also provide the future CCK for the LA which the MS has 
indicated in the U-OTAR CCK DEMAND PDU and whether the CCK provided is in use in 
other LAs or is used throughout the SwMI. The SDU is coded according to the MM protocol 
description. There shall be no P-bit in the PDU coding preceding the SDU information 
element. 



18.4.1.4.3 



D-PREPARE-FAIL 



Message: 



Response to: 
Response expected: 
Short description: 



D-PREPARE-FAIL 



U-PREPARE 



Upon receipt from the SwMI the message shall be used by the MS-MLE as a 
preparation failure, while announcing cell reselection to the old cell. 

Table 18.5: D-PREPARE-FAIL PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


D-PREPARE-FAIL 


Fail cause 


2 


1 


M 




SDU 








See note 


NOTE: The SDU may carry an MM registration PDU. The SDU is coded according to the MM 
protocol description. There shall be no P-bit in the PDU coding preceding the SDU 
information element. 
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18.4.1.4.4 D-RESTORE-ACK 

• Message: D-RESTORE-ACK 



Response to: 
Response expected: 
Short description: 



U-RESTORE 



Upon receipt from the SwMI, the message shall indicate to the MS-MLE an 
acknowledgement of the C-Plane restoration on the new selected cell. 

Table 18.6: D-RESTORE-ACK PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


D-RESTORE-ACK 


SDU 








See note 


NOTE: This PDU shall carry a CMCE D-CALL RESTORE PDU which can be used to restore a call 
after cell reselection. The SDU is coded according to the CMCE protocol description. There 
shall be no P-bit in the PDU coding preceding the SDU information element. 



18.4.1.4.5 

• Message: 

• Response to: 

• Response expected: 

• Short description: 



D-RESTORE-FAIL 

D-RESTORE-FAIL 
U-RESTORE 



Upon receipt from the SwMI, the message shall indicate to the MS-MLE a 
failure in the restoration of the C-Plane on the new selected cell. 

Table 18.7: D-RESTORE-FAIL PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


D-RESTORE-FAIL 


Fail cause 


2 


1 


M 





18.4.1.4.5a 



D-CHANNEL RESPONSE 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



D-CHANNEL RESPONSE 
U-CHANNEL REQUEST 



The message shall be sent by the SwMI in response to an MS request for an 
assigned channel replacement. 

Table 18.8: D-CHANNEL RESPONSE PDU 



Information element 


Length 


Type 


C/O/IW 


Remark 


PDU type 


3 


1 


M 


D-CHANNEL RESPONSE 


Channel response type 


1 


1 


M 




Reason for the channel request 


3 


1 


M 




Channel request retry delay 


4 


1 


M 




Reserved 


8 


2 





See note 


Reserved 


8 


2 





See note 


NOTE: In the present document, this element shall not be included 
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18.4.1.4.6 



U-PREPARE 



Message: 



Response to: 
Response expected: 
Short description: 



U-PREPARE 



D-NEWCELL/D-NWRK-BROADCAST/D-PREPARE-FAIL 

The message shall be sent on the serving cell to the SwMI by the MS-MLE, 
when preparation of cell reselection to a neighbour cell is in progress. 

Table 18.9: U-PREPARE PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


U-PREPARE 


Cell identifier 


5 


2 







SDU 








See note 


NOTE: The SDU may carry an MM registration PDU which is used to forward register to a new cell 
during announced type 1 cell reselection or a U-OTAR CCK DEMAND PDU which is used 
to request the Common Cipher Key (CCK) of the new cell. The SDU is coded according to 
the MM protocol description. There shall be no P-bit in the PDU coding preceding the SDU 
information element. 



18.4.1.4.7 



U-RESTORE 



Message: 



Response to: 
Response expected: 
Short description: 



U-RESTORE 



D-RESTORE-ACK/D-RESTORE-FAIL 



The message shall be sent by the MS-MLE, when restoration of the C-Plane 
towards a new cell is in progress. 

Table 18.10: U-RESTORE PDU 



Information element 


Length 


Type 


C/O/IM 


Remark 


PDU type 


3 


1 


M 


U-RESTORE 


MCC 


10 


2 





See note 1 


MNC 


14 


2 





See note 1 


LA 


14 


2 





See note 1 


SDU 








See note 2 


NOTE 1 : The element is present in the PDU if its value on the new cell is different from that on the 

old cell. 
NOTE 2: This PDU shall carry a CMCE U-CALL RESTORE PDU which shall be used to restore a call 

after cell reselection. The SDU is coded according to the CMCE protocol. There shall be no 

P-bit in the PDU coding preceding the SDU information element. 
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18.4.1.4.8 



U-CHANNEL ADVICE 



Message: 



U-CHANNEL ADVICE 



Response to: 

Response expected: 

Short description: The message advises the SwMI of usable channel classes and the data priority of 

SN PDUs awaiting access to a packet data channel. 

Table 18.11: U-CHANNEL ADVICE PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


U-CHANNEL ADVICE 


Number of channel class Identifiers 


2 


1 


M 


See note 1 . 


Channel class identifier 


4 




C 


Repeatable, see note 2. 


Data priority 


3 


2 







SDU 








See note 3. 


NOTE 1 : Shall indicate the number of channel class identifier information elements: 

OO2 means one channel class identifier information element i.e. four bits; 

01 2 means two channel class identifier information elements i.e. eight bits; 

IO2 means three channel class identifier information elements i.e. 12 bits; 

1 12 means four channel class identifier information elements i.e. 16 bits. 
NOTE 2: Shall be present as many times as indicated by the "number of channel class identifiers" 

information element. 
NOTE 3: The SDU shall be an SNDCP SN-DATA TRANSMIT REQUEST PDU, SN-PAGE RESPONSE 

PDU or an SN-RECONNECT PDU. The SDU is coded according to the SNDCP protocol 

description. There shall be no P-bit in the PDU coding preceding the SDU information element. 



NOTE: This PDU uses a minimum of 13 bits before the SDU, including the MLE protocol identifier and the 
O-bit. It uses 17 bits (including a P-bit) when the data priority element is present. For example, this 
allows the following U-CHANNEL ADVICE PDU plus SN-DATA TRANSMIT REQUEST PDU 
combinations to be transmitted with an SSI without fragmentation: 

In SCH-Q/RA: 

one channel class identifier with data priority, without SNEI, without resource request, 
without the 20-bit reserved element and without a reservation requirement from layer 2; 

one channel class identifier without data priority, without SNEI, without resource request, 
without the 20-bit reserved element and with a reservation requirement from layer 2; 

two channel class identifiers without data priority, without SNEI, without resource request, 
without the 20-bit reserved element and without a reservation requirement from layer 2; or 

In SCH/HU: 

one channel class identifier with data priority, with SNEI, with the 10-bit resource request, 
without the 20-bit reserved element and without a reservation requirement from layer 2; or 

one channel class identifier with data priority, without SNEI, without resource request, with 
the 20-bit reserved element and with a reservation requirement from layer 2; or 

one channel class identifier without data priority, without SNEI, with the 10-bit resource 
request, with the 20-bit reserved element and without a reservation requirement from layer 2. 

four channel class identifiers without data priority, without SNEI, with the 10-bit resource 
request, without the 20-bit reserved element and with a reservation requirement from layer 2. 

(The first three SCH/HU examples are exact fits in an SCH/HU logical channel.) 
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1 8.4.1 .4.9 U-CHANNEL REQUEST 

• Message: U-CHANNEL REQUEST 

• Response to: 

• Response expected: 



Short description: 



The message shall be sent by the MS-MLE to request replacement of an assigned 
channel. 



Table 18.12: U-CHANNEL REQUEST PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


U-CHANNEL REOUEST 


Reason for the channel request 


3 


1 


M 




Number of requested channel class 
identifiers 


3 


2 







Channel class Identifier 


4 




C 


See note 1 


Number of requested channel 
identifiers 


3 


2 







Channel identifier 


4 




C 


See note 2 


Reserved 


6 


2 





See note 3 


NOTE 1 : The element shall be included as many times as indicated by the "Number of requested 

channel class identifiers" element. 
NOTE 2: The element shall be included as many times as indicated by the "Number of requested 

channel identifiers" element. 
NOTE 3: Shall not be used in the present document. 
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18.4.1.4.10 

• Message: 



U-SECTOR ADVICE 

U-SECTOR ADVICE 



Response to: 
Response expected: 
Short description: 



The message advises the SwMI of sectored channels on the current cell which the 
MS can use from its current location. 

Table 18.13: U-SECTOR ADVICE PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 


U-SECTOR ADVICE 


Number of channel identifiers 


2 


1 


M 


See note 1 


Channel identifier 


4 




C 


Repeatable, see note 2 


Data priority 


3 


2 







SDU 








See note 3 


NOTE 1 : Shall indicate the number of channel identifier information elements: 

OO2 means one channel identifier information element i.e. four bits; 

01 2 means two channel identifier information elements i.e. eight bits; 

IO2 means three channel identifier information elements i.e. 12 bits; 

1 12 means four channel identifier information elements i.e. 16 bits. 
NOTE 2: Shall be present as many times as indicated by the "number of channel identifiers" 

information element. 
NOTE 3: The SDU shall carry an SNDCP SN-DATA TRANSMIT REOUEST PDU, 

SN-PAGE-RESPONSE PDU or an SN-RECONNECT PDU. The SDU is coded according to 

the SNDCP protocol description. There shall be no P-bit in the PDU coding preceding the 

SDU information element. 



NOTE: This PDU uses a minimum of 13 bits before the SDU, including the MLE protocol identifier and the 
O-bit. It uses 17 bits (including a P-bit) when the data priority element is present. For example, this 
allows the following U-CHANNEL ADVICE PDU plus SN-DATA TRANSMIT REQUEST PDU 
combinations to be transmitted with an SSI without fragmentation: 

in SCH-Q/RA: 

with one suggested channel, with data priority, without SNEI, without resource request, 
without the 20-bit reserved element and without a reservation requirement from layer 2. 

with one suggested channel, without data priority, without SNEI, without resource request, 
without the 20-bit reserved element and with a reservation requirement from layer 2; 

in SCH/HU: 

with one suggested channel, with data priority, with SNEI, with the 10-bit resource request, 
without the 20-bit reserved element and without a reservation requirement from layer 2; or 

with one suggested channel, with data priority, without SNEI, without resource request, with 
the 20-bit reserved element and with a reservation requirement from layer 2; or 

with one suggested channel, without data priority, without SNEI, with the 10-bit resource 
request, with the 20-bit reserved element and without a reservation requirement from layer 2. 

(The SCH/HU combinations are exact fits in an SCH/HU logical channel.) 

1 8.4.2 Broadcast PDUs at the TLB-SAP 

PDUs at the TLB SAP shall be transported using the BNCH, BNCH-Q and BSCH logical channels. D-MLE-SYNC 
shall use the BSCH logical channel, D-MLE-SYSINFO shall use the BNCH logical channel and D-MLE-SYSINFO-Q 
shall use the BNCH-Q logical channel. 
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18.4.2.1 



D-MLE-SYNC 



Message: 
Response to: 
Response expected: 
Short description: 



D-MLE-SYNC 



This message shall inform the MS about information that is necessary for 
performing cell reselection. The message can only be recognized as a MAC to 
MAC message on the Broadcast Synchronization CHannel (BSCH). 

Table 18.14: D-MLE-SYNC PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


MCC 


10 




M 


D-MLE-SYNC 


MNC 


14 




M 




Neighbour cell broadcast 


2 




M 




Cell service level 


2 




M 




Late entry information 


1 




M 





This PDU shall not contain an "O" bit and shall be 29 bits in length. 



18.4.2.2 



D-MLE-SYSINFO 



Message: 
Response to: 
Response expected: 
Short description: 



D-MLE-SYSINFO 



This message is used for informing the MS about MLE information for the 
serving cell. The message can only be recognized as a MAC to MAC message 
on the BNCH. 

Table 18.15: D-MLE-SYSINFO PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


LA 


14 


1 


M 


D-MLE-SYSINFO 


Subscriber class 


16 


1 


M 




BS service details 


12 


1 


M 





This PDU shall not contain an "O" bit and shall be 42 bits in length. 
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18.4.2.3 



D-MLE-SYSINFO-Q 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



D-MLE-SYSINFO-Q 



This message is used for informing the MS about MLE information for the 
serving cell. The message can only be recognized as a MAC to MAC message 
on the BNCH-Q. 

Table 18.16: D-MLE-SYSINFO-Q PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


Neighbour cell broadcast 


2 




M 


D-MLE-SYSINFO-Q 


Cell service level 


2 




M 




Late entry supported 


1 




M 




LA 


14 




M 




Subscriber class 


16 




M 




BS service details 


12 




M 





This PDU shall not contain an "O" bit and shall be 47 bits in length. 

18.5 Information elements coding 
18.5.1 Cell reselection types supported 

The cell reselection types supported information element shall define whether SwMI supports forward registration and 
if expedited cell reselection is needed on the neighbour cell as defined in table 18.17. 

Table 18.17: Cell reselection types supported information element 



Information element 


Length 


Value 


Remark 


Cell reselection types supported 


2 


OO2 


Forward registration is not supported 


OI2 


Forward registration is not supported, expedited cell 
reselection recommended 


IO2 


Forward registration Is supported 


II2 


Forward registration is supported, expedited cell 
reselection recommended 



18.5.1a Bandwidth 

The bandwidth information element shall indicate an RF bandwidth of an channel or channel class, as defined in 
table 18.18. 

Table 18.18: Bandwidth information element 



Information element 


Length 


Value 


Remark 


Bandwidth 


3 


OOO2 


25 kHz 


001 2 


50 kHz 


01 O2 


100 kHz 


0112 


150 kHz 


1002 


Reserved 


etc. 


etc. 


III2 


Reserved 
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1 8.5.2 BS service details 

The BS service details information element shall contain information about which services are supported by the SwMI 
on a particular cell as defined in table 18.19. 

Table 18.19: BS Service details information element 



Information element 


Length 


Value 


Remark 


Registration 







Registration not required on this cell 


1 


Registration mandatory on this cell 


De-registration 







De-registration not required on this cell 


1 


De-registration mandatory on this cell 


Priority cell 







Cell is not a priority cell 


1 


Cell is a priority cell 


Minimum mode service 







Cell may use minimum mode 


1 


Cell never uses minimum mode 


Migration 







Migration is not supported by this cell 


1 


Migration is supported by this cell 


System wide services 







System wide services temporarily not supported 


1 


Normal mode 


TETRA voice service 







TETRA voice service is not supported on this cell 


1 


TETRA voice service is supported on this cell 


Circuit mode data service 







Circuit mode data service is not supported on this cell 


1 


Circuit mode data service is supported on this cell 


Reserved 







Default value 


1 


Reserved for future expansion 


SNDCP service 







SNDCP service is not available on this cell 


1 


SNDCP service is available on this cell 


Air interface encryption 
service 







Air interface encryption is not available on this cell 


1 


Air interface encryption is available on this cell 


Advanced link supported 







Advanced link is not supported on this cell (see note 1) 


1 


Advanced link is supported on this cell (see note 2) 


NOTE 1 : If "0", neither the original advanced link nor the extended advanced link is supported on this cell. 
NOTE 2: If "1 ", the original advanced link is supported on this cell, and the extended advanced link may be 

supported on this cell (see the extended services broadcast information element in clause 21 .4.4.1). 
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1 8.5.2a BS transmit power relative to tine main carrier 

The BS transmit power relative to the main carrier information element shall be used give the ratio of the BS transmit 
power on an RF channel or channel class to the BS transmit power on the MCCH controlling use of that RF channel or 
channel class, as defined in table 18.20. 

Table 18.20: BS transmit power relative to the main carrier information element 



Information element 


Length 


Value 


Remark 


BS transmit power relative to 
the main carrier 


5 


OOOOO2 


Reserved 


0001 O2 


etc. 


001 OO2 


Reserved 


001012 


-22 dB 


001 IO2 


-20 dB 


001112 


-18dB 


010002 


-16dB 


010012 


-14dB 


010102 


-12dB 


010112 


-lOdB 


011002 


-8dB 


011012 


-6dB 


011102 


-4dB 


011112 


-2dB 


100002 


OdB 


100012 


2dB 


100102 


4dB 


100112 


6dB 


101002 


8dB 


101012 


lOdB 


101102 


12dB 


101112 


14dB 


110002 


16dB 


110012 


IBdB 


110102 


20 dB 


110112 


22 dB 


111002 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 



This figure shall include the BS relative antenna gains; i.e. it is the BS effective radiated power (ERP) into the 
concentric channel or sectored channel relative to the BS ERP of the main carrier. 

18.5.2b Carrier number 

The carrier number information element shall define the carrier number for a channel as defined in table 18.21. See the 
channel allocation element in clause 21 and TS 100 392-15 [18] for a full description of carrier numbering. 

Table 18.21 : Carrier number information element 



Information element 


Length 


Value 


Remark 


Carrier number 


12 




Carrier number of channel as defined in clause 21 
and TS 100 392-15 [18] 
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1 8.5.2c Carrier number extension 

The carrier number extension information element shall define extended carrier numbering information as defined in 
table 18.22. See the channel allocation element in clause 21 and TS 100 392-15 [18] for a full description of carrier 
numbering. 

Table 18.22: Carrier number extension information element 



Information element 


Length 


Value 


Remark 


Frequency band 


4 




Provision for different frequency bands as defined in 
clause 21 and TS 100 392-15 [18] 


Offset 


2 


OO2 


No offset 


OI2 


+6,25 kHz offset 


IO2 


-6,25 kHz offset 


II2 


+12,5 kHz offset 


Duplex spacing 


3 




Provision for different duplex spacing as defined in 
clause 21 and TS 100 392-15 [18] 


Reverse operation 


1 





Normal 


1 


Reverse 



1 8. 5. 2d Carrier number extension flag 

The carrier number extension flag information element shall deterine whether the carrier number extension element is 
present, as defined in table 18.23. 

Table 18.23: Carrier number extension flag information element 



Information element 


Length 


Value 


Remark 


Carrier number extension flag 


1 





Carrier number extension not included 


1 


Carrier number extension included 



18.5.3 Cell identifier 

The cell identifier information element shall be used to identify a neighbour cell as defined in table 18.24. The serving 
cell shall attach a cell identifier to each neighbour cell whenever the serving cell broadcasts information about that 
neighbour cell. The cell identifier can then be used subsequently to refer to that neighbour cell. When the SwMI assigns 
a cell identifier, it shall then be able to map this identifier to a physical cell whenever the MS uses the cell identifier (for 
example, in a U-PREPARE PDU). 

The cell identifier may also be set equal to "OOOOO2" to initiate the neighbour cell enquiry procedure which prompts the 
SwMl to send the D-NWRK-BROADCAST PDU when the MS does not yet have the neighbour cell information. 

Table 18.24: Cell identifier information element 



Information element 


Length 


Value 


Remark 


Cell identifier 


5 


OOOOO2 


Neighbour cell enquiry 


00001 2 


Valid cell identifier 


etc. 


etc. 


IIIII2 


Valid cell identifier 
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18.5.4 Cell re-select parameters 



The cell re-select parameters information element shall define the threshold parameters for the cell reselection 
procedures in the MS as defined in table 18.25. 

SLOW_RESELECT_THRESHOLD is the maximum level above the FAS T_RESELECT_THRES HOLD for a radio 
improvable link i.e. SLOW_RESELECT_THRESHOLD = FAST_RESELECT_THRESHOLD + 
SLOW_RESELECT_THRESHOLD_ABOVE_FAST. 

FAST_RESELECT_THRESHOLD is the maximum level above CI = "0" for a radio relinquishable link. 

SLOW_RESELECT_HYSTERESIS is the hysteresis for a radio improvable link. 

FAST_RESELECT_HYSTERESIS is the hysteresis for a radio relinquishable link. 

Table 18.25: Cell re-select parameters information element 



Information element 


Length 


Value 


Remark 


SLOW_RESELECT_THRESHOLD_ABOVE_FAST 


4 


OOOO2 


OdB 


OOOI2 


2dB 


etc. 


etc. 


IIII2 


30 dB 


FAST_RESELECT_THRESHOLD 


4 


OOOO2 


OdB 


OOOI2 


2dB 


etc. 


etc. 


IIII2 


30 dB 


SLOW_RESELECT HYSTERESIS 


4 


OOOO2 


OdB 


OOOI2 


2dB 


etc. 


etc. 


IIII2 


30 dB 


FAST_RESELECT_HYSTERESIS 


4 


OOOO2 


OdB 


OOOI2 


2dB 


etc. 


etc. 


IIII2 


30 dB 



18.5.5 Cell service level 

The cell service level information element shall define the level of service a MS may receive in a cell as defined in 
table 18.26. It may relate to the traffic loading in a cell. 

Table 18.26: Cell service level information element 



Information element 


Length 


Value 


Remark 


Cell service level 


2 


OO2 


Cell load unknown 


OI2 


Low cell load 


IO2 


Medium cell load 


II2 


High cell load 
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18.5.5a Channel characteristics 

The channel characteristics information element shall indicate the characteristics of an RF channel or channel class, as 
defined in table 18.27. 

Table 18.27: Channel characteristics information element 



Information element 


Length 


Type 


C/O/M 


Remark 


Modulation mode 


3 




M 




Bandwidth 


3 




M 




IVIaximum MS transmit power 


3 




M 




Minimum RX access level 


4 




M 




Reserved 


5 




M 





18.5.5b Channel class 

The channel class information element shall indicate a channel class, as defined in table 18.28. 

Table 18.28: Channel class information element 



Information element 


Length 


Type 


C/O/M 


Remark 


Channel class identifier 


4 


1 


M 




Channel characteristics 


18 


1 


M 




BS transmit power relative to main carrier 


5 


1 


M 





18.5.5c Channel class identifier 

The channel class identifier information element provides a reference label to a channel class, as defined in table 18.29. 
Table 18.29: Channel class identifier information element 



Information element 


Length 


Value 


Remark 


Channel class identifier 


4 


OOOO2 


The channel class is not specified 


0001 2 


Conforming channel class 


001 O2 


Valid channel class identifier 


etc 


etc. 


IIII2 


Valid channel class identifier 



1 8.5.6 Channel command valid 

The channel command valid information element shall indicate to the MS-MLE when to initiate a channel change as a 
result of cell reselection as defined in table 18.30. 

Table 18.30: Channel command valid information element 



Information element 


Length 


Value 


Remark 


Channel command valid 


2 


OO2 


Follow MAC channel change 

(follow channel allocation in MAC header) 


OI2 


Change channel immediately 


IO2 


No channel change - wait for next D-NEW-CELL 


II2 


Reserved 
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18.5.6a Channel identifier 

The channel identifier information element provides a reference label to a channel, as defined in table 18.31. 

Table 18.31 : Channel identifier information element 



Information element 


Length 


Value 


Remark 


Channel identifier 


4 


OOOO2 


Reserved 


0001 2 


Valid channel identifier 


etc. 


etc. 


IIII2 


Valid channel identifier 



18.5.6b CInannel request retry delay 

The channel request retry delay information element shall indicate the minimum delay, as defined in table 18.32, before 
the MS is permitted to transmit a U-CHANNEL REQUEST PDU containing the same value of "reason for the channel 
request" information element as used in a previously transmitted U-CHANNEL REQUEST PDU. 

Table 18.32: Channel request retry delay information element 



Information element 


Length 


Value 


Remark 


Channel request retry delay 


4 


OOOO2 


No delay 


OOOI2 


5s 


001 O2 


10s 


OOII2 


15s 


OIOO2 


20 s 


OIOI2 


25 s 


OIIO2 


30 s 


OIII2 


40 s 


IOOO2 


50 s 


IOOI2 


60s 


IOIO2 


80s 


IOII2 


120 s 


IIOO2 


300 s 


IIOI2 


Reserved 


etc. 


etc. 


IIIO2 


Reserved 


IIII2 


Retransmission not permitted 



18.5.6c Channel response type 

The channel response type information element shall indicate the type of response, as defined in table 18.33. 
Table 18.33: Channel response type information element 



Information element 


Length 


Value 


Remark 


Channel response type 


1 


O2 


Request accepted 


I2 


Request rejected 
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18.5.6d Data priority 

The data priority information element shall indicate to the SwMI the data priority of SN PDUs waiting for access to a 
packet data channel as defined in table 18.34. 

Table 18.34: Data priority information element 



Information element 


Length 


Value 


Remark 


Data priority 


3 


OOO2 


Data priority (lowest data priority) 


001 2 


Data priority 1 


etc. 


etc. 


III2 


Data priority 7 (highest data priority) 



18.5.7 Fail cause 

The Fail cause information element shall indicate to the MS the failure cause as a result of requesting an MLE service in 
the SwMI as defined in table 18.35. 

Table 18.35: Fail cause information element 



Information element 


Length 


Value 


Remark 


Fail cause 


2 


OO2 


Neighbour cell enquiry not available (neighbouring cell 

enquiry); 

Temporary break in service (cell reselection); 


OI2 


Cell reselection type not supported, perform registration 
and call restoration on the selected cell 


IO2 


MS not allowed on cell 


II2 


Restoration cannot be done on cell 



1 8.5.8 Late entry supported 

The late entry supported information element shall indicate to the MS whether or not late entry can be supported by the 
cell as defined in tablel8.36. 

Table 18.36: Late entry supported information element 



Information element 


Length 


Value 


Remark 


Late entry supported 


1 





Late entry not supported 


1 


Late entry available 



18.5.9 Location Area (LA) 

The Location Area information (LA) element shall define the LA in which a cell is located, either the serving cell or a 
neighbour cell as defined in table 18.37. 

Table 18.37: LA information element 



Information element 


Length 


Value 


Remark 


LA 


14 
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18.5.10 Main carrier number 

The main carrier number information element shall define the main carrier number for a neighbour cell as defined in 
table 18.38. See the channel allocation element in clause 21 and TS 100 392-15 [18] for a full description of carrier 
numbering. 

Table 18.38: Main carrier number information element 



Information element 


Length 


Value 


Remark 


Main carrier 


12 




IVIain carrier number of neighbour cell as defined in 
clause 21 and TS 100 392-15 [18] 



1 8.5. 1 1 Main carrier number extension 

The main carrier number extension information element shall define extended carrier numbering information as defined 
in table 18.39. See the channel allocation element in clause 21 and TS 100 392-15 [18] for a full description of carrier 
numbering. 

Table 18.39: IVIain carrier number extension information element 



Information element 


Length 


Value 


Remark 


Frequency band 


4 




Provision for different frequency bands as defined in 
clause 21 and TS 100 392-15 [18] 


Offset 


2 


OO2 


No offset 


OI2 


+6,25 kHz offset 


IO2 


-6,25 kHz offset 


II2 


+12,5 kHz offset 


Duplex spacing 


3 




Provision for different duplex spacing as defined in 
clause 21 and TS 100 392-15 [18] 


Reverse operation 


1 





Normal 






1 


Reverse 



1 8.5.1 2 Minimum Rx access level 

The minimum RX access level information element shall indicate the minimum received signal level required at the 
SwMI in a cell, either the serving cell or a neighbour cell as defined in table 18.40. 

Table 18.40: IVIinimum Rx access level information element 



Information element 


Length 


Value 


Remark 


RXLEV_ACCESS_MIN_MCELL 


4 


OOOO2 


-125 dBm 


OOOI2 


-120 dBm 


etc. 


etc. 


IIII2 


-50 dBm (5 dB steps) 
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1 8.5.1 3 Maximum MS transmit power 

The maximum MS transmit power information element shall indicate to the MS the maximum power that is allowed to 
be transmitted in either the serving cell or a neighbour cell, or in a sectored channel or non-conforming concentric 
channel as defined in table 18.41. 

Table 18.41 : Maximum MS transmit power information element 



Information element 


Length 


Value 


Remark 


MS_TXPWR_MAX_MCELL 


3 


OOO2 


Reserved 


001 2 


15dBm 


01 O2 


20dBm 


0112 


25dBm 


1002 


30dBm 


1012 


35dBm 


1102 


40dBm 


1112 


45dBm 



18.5.14 MCC 

The MCC information element shall indicate which country a cell is located in as defined in table 18.42. Refer to 
annex I for country code values. 

Table 18.42: MCC information element 



Information element 


Length 


Value 


Remark 


MCC 


10 







18.5.15 MNC 

The element shall indicate which network a cell is located in as defined in table 18.43. 

Table 18.43: MNC information element 



Information element 


Length 


Value 


Remark 


MNC 


14 




See EN 300 392-1 [6] clause 7. 



18.5.1 5a Modulation mode 

The modulation mode information element shall indicate to the SwMI the modulation mode of an RF channel, as 
defined in table 18.44. 

Table 18.44: Modulation mode information element 



Information element 


Length 


Value 


Remark 


Modulation mode 


3 


OOO2 


7I/4-DQPSK modulation mode 


OOI2 


D8PSK modulation mode 


01 O2 


QAM modulation mode 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 
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1 8.5.1 6 Neighbour cell broadcast 

The neighbour cell broadcast information element shall indicate how an MS can obtain information about neighbour 
cells as defined in table 18.45. The neighbour cell information may be broadcast by the SwMI using the 
D-NWRK-BROADCAST PDU or the MS may use U-PREPARE to enquire for the D-NWRK-BROADCAST 
information. 

Table 18.45: Neighbour cell broadcast information element 



Information element 


Length 


Value 


Remark 


D-NWRK-BROADCAST 
broadcast supported 


1 





Not supported 


1 


Supported 


D-NWRK-BROADCAST 
enquiry supported 


1 





Not supported 


1 


Supported 



18.5. 16a Neighbour cell channel class 

The neighbour cell channel class information element shall indicate a channel class available on a neighbour cell, as 
defined in table 18.46. 

Table 18.46: Neighbour cell channel class information element 



Information element 


Length 


Type 


C/O/M 


Remark 


Cell identifier 


5 


1 


M 




Channel class 


27 


1 


M 
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18.5.17 Neighbour cell information 

The neighbour cell information element shall contain information about a neighbour cell as defined in table 18.47. 

Table 18.47: Neighbour cell information element 



Information element 


Length 


Type 


C/O/M 


Remark 


Cell identifier 


5 




M 




Cell reselection types supported 


2 




M 




Neighbour cell synchronized 


1 




M 




Cell service level 


2 




M 




IVIain carrier number 


12 




M 




Main carrier number extension 


10 


2 





See note 1 


MCC 


10 


2 





See note 2 


MNC 


14 


2 





See note 2 


LA 


14 


2 





See note 2 


Maximum MS transmit power 


3 


2 





See note 2 


Minimum RX access level 


4 


2 





See note 2 


Subscriber class 


16 


2 





See note 2 


BS service details 


12 


2 





See note 2 


Timeshare cell and Al encryption information 


5 


2 





See note 3 


TDMA frame offset 


6 


2 





See note 4 


NOTE 1 : If not present, the "Main carrier number" element shall fully define the frequency of the 

neighbour cell main carrier. The neighbour cell extended carrier numbering information shall 
be assumed to be the same as that of the serving cell. 

NOTE 2: If not present, the neighbour cell parameter shall be assumed to be the same as that of the 
serving cell. 

NOTE 3: If not present, it shall be assumed that the neighbour cell is not operating in a discontinuous 

mode of operation and that the neighbour cell's Al encryption parameters are the same as that 
of the serving cell. If the element contains timeshare cell information, then Al encryption 
information shall not be changed in the MS. If the element contains Al encryption information, 
then timeshare cell information shall not be changed in the MS. 

NOTE 4: If present, the neighbour cell shall be synchronized to the serving cell and this element shall 

indicate the frame offset for the neighbour cell. If the cells are synchronized and this element Is 
not present, it shall be assumed by the MS that the TDMA frame offset = 0. 



For this element there shall be a P-bit for each type 2 element contained within. 

18.5.1 7a Neighbour cell sectored channel detail 

The neighbour cell sectored channel detail information element shall indicate a sectored channel available on a 
neighbour cell, as defined in table 18.48. 

Table 18.48: Neighbour cell sectored channel detail information element 



Information element 


Length 


Type 


C/O/M 


Remark 


Cell identifier 


5 


1 


M 




Sectored channel detail 


variable 


1 


M 





1 8.5.1 8 Neighbour cell synchronized 

The neighbour cell synchronized information element shall indicate whether or not the neighbour cell is synchronized to 
the serving cell as defined in table 18.49. 

Table 18.49: Neighbour cell synchronized information element 



Information element 


Length 


Value 


Remark 


Neighbour cell synchronized 


1 





Neighbour cell is not synchronized 


1 


Neighbour cell is synchronized 
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18.5.1 8a Number of channel classes (for serving cell) 

The number of channel classes (for serving cell) information element shall indicate how many "channel class" elements 
follow as defined in table 18.50. 

Table 18.50: Number of channel classes (for serving cell) information element 



Information element 


Length 


Value 


Remark 


Number of channel classes (for 
serving cell) 


4 


OOOO2 


No channel classes available 


OOOI2 


Number of channel class elements contained in 
this PDU 


etc. 


etc. 


IIII2 


Number of channel class elements contained in 
this PDU 



1 8.5.1 8b Number of channel class identifiers 

The number of channel class identifiers information element shall indicate how many channel class identifiers follow, 
as defined in table 18.51. 

Table 18.51 : Number of channel class identifiers information element 



Information element 


Length 


Value 


Remark 


Number of channel class 
identifiers 


2 


OO2 


One "channel class identifier" element is included 
in this PDU 


OI2 


Two "channel class identifier" elements are 
included in this PDU 


IO2 


Three "channel class identifier" elements are 
included in this PDU 


II2 


Four "channel class identifier" elements are 
included in this PDU. 



1 8.5.1 8c Number of channel icjentifiers 

The number of channel identifiers information element shall indicate how many channel identifiers follow, as defined in 
table 18.52. 

Table 18.52: Number of channel identifiers information element 



Information element 


Length 


Value 


Remark 


Number of channel identifiers 


2 


OO2 


One "channel identifier" element is included in this 
PDU 


OI2 


Two "channel identifier" elements are included in 
this PDU 


IO2 


Three "channel identifier" elements are included 
in this PDU 


II2 


Four "channel identifier" elements are included in 
this PDU. 
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1 8.5.1 8d Number of neighbour cell channel classes 

The number of neighbour cell channel classes information element shall indicate how many "Neighbour cell channel 
class" elements follow as defined in table 18.53. 

Table 18.53: Number of neighbour cell channel classes information element 



Information element 


Length 


Value 


Remark 


Number of neighbour cell channel 
Classes 


5 


OOOOO2 


No neighbour cell channel classes available 


00001 2 


Number of "Neighbour cell channel class" 
elements contained in this PDU 


etc. 


etc. 


IIIII2 


Number of "Neighbour cell channel class" 
elements contained in this PDU 



18.5.19 Number of neighbour cells 

The number of neighbour cells information element shall indicate how many "Neighbour cell information" elements 
follow as defined in table 18.54. 

Table 18.54: Number of neighbour cells information element 



Information element 


Length 


Value 


Remark 


Number of neighbour cells 


3 


OOO2 


No neighbour cell information available 


001 2 


Number of "Neighbour cell information" elements 
contained in this PDU 


etc. 


etc. 


III2 


Number of "Neighbour cell information" elements 
contained in this PDU 



1 8.5.1 9a Number of neighbour cell sectored channels details 

The number of neighbour cell sectored channels details information element shall indicate how many "Neighbour cell 
sectored channel detail" elements follow as defined in table 18.55. 

Table 18.55: Number of neighbour cell sectored channels details information element 



Information element 


Length 


Value 


Remark 


Number of neighbour cell 
sectored channel details 


6 


OOOOOO2 


No sectored channel details available 


000001 2 


Number of "Sectored channel detail" elements for 
serving cell contained in this PDU 


etc. 


etc. 


IIIIII2 


Number of "Sectored channel detail" elements for 
serving cell contained in this PDU 
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18.5.1 9b Number of requested channel class identifiers 

The number of requested channel class identifiers information element shall indicate how many channel class identifiers 
follow, as defined in table 18.56. 

Table 18.56: Number of requested channel class identifiers information element 



Information element 


Length 


Value 


Remark 


Number of requested channel 
class identifiers 


3 


OOO2 


One "channel class identifier" element is included 
in this PDU 


001 2 


Two "channel class identifier" elements are 
included in this PDU 


etc. 


etc. 


III2 


Eight "channel class identifier" elements are 
included in this PDU. 



1 8.5.1 9c Number of requested channel identifiers 

The number of requested channel identifiers information element shall indicate how many channel identifiers follow, as 
defined in table 18.57. 

Table 18.57: Number of requested channel identifiers information element 



Information element 


Length 


Value 


Remark 


Number of channel identifiers 


3 


OOO2 


One "channel identifier" element is included in this 
PDU 


001 2 


Two "channel identifier" elements are included in 
this PDU 


etc. 


etc. 


III2 


Eight "channel identifier" elements are included in 
this PDU. 



1 8.5.1 9d Number of sectored channels details (for serving cell) 

The number of sectored channel details information element shall indicate how many "Sectored channel details" 
elements follow as defined in table 18.58. 

Table 18.58: Number of sectored channel details information element 



Information element 


Length 


Value 


Remark 


Number of sectored channel 
details (for serving cell) 


5 


OOOOO2 


No sectored channel details available 


00001 2 


Number of "Sectored channel detail" elements for 
serving cell contained in this PDU 


etc. 


etc. 


IIIII2 


Number of "Sectored channel detail" elements for 
serving cell contained in this PDU 
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18.5.20 PDUtype 

The PDU type information element shall indicate the PDU type for each of the MLE protocol PDUs. The PDU type 
shall have a separate definition for the uplink and downlink directions as shown in the table 18.59. 

Table 18.59: PDU type information element 



Information element 


Length 


Value 


Remark 


DOWNLINK 


UPLINK 


PDU type 


3 


OOO2 


D-NEW-CELL 


U-PREPARE 


OOI2 


D-PREPARE FAIL 


Reserved 


01 O2 


D-NWRK-BROADCAST 


U-SECTOR ADVICE 


OII2 


D-NWRK-BROADCAST EXTENSION 


U-CHANNEL ADVICE 


IOO2 


D-RESTORE-ACK 


U-RESTORE 


IOI2 


D-RESTORE-FAIL 


Reserved 


11 O2 


D-CHANNEL RESPONSE 


U-CHANNEL REQUEST 


III2 


Reserved 


Reserved 



18.5.21 Protocol discriminator 

The protocol discriminator information element shall indicate which protocol the PDU belongs to as defined in 
table 18.60. MM, CMCE and SNDCP PDUs are routed by the MLE to the relevant SAP. MLE protocol PDUs are 
processed by the MLE protocol entity and TETRA management entity PDUs by the TETRA management functional 
entity within the MLE. 

Table 18.60: Protocol discriminator information element 



Information element 


Length 


Value 


Remark 


Protocol discriminator 


3 


OOO2 


Reserved 


OOI2 


IVIIVI protocol 


01 O2 


CIVICE protocol 


OII2 


Reserved 


IOO2 


SNDCP protocol 


IOI2 


IVILE protocol 


IIO2 


TETRA management entity protocol 


III2 


Reserved for testing 



1 8.5.21 a Reason for tine cinannel request 

The reason for the channel request information element shall indicate the reason for the MS's assigned channel 
replacement request, as defined in table 18.61. 

Table 18.61 : Reason for the channel request information element 



Information element 


Length 


Value 


Remark 


Reason for the channel request 


3 


OOO2 


Unspecified reason 


OOI2 


Current channel is radio relinquishable 


01 O2 


Current channel is radio improvable 


OII2 


Higher level of service is requested 


IOO2 


Reserved 


etc. 


etc. 


III2 


Reserved 
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18.5.21b Sectored channel detail 

The sectored channel detail information element shall indicate the details of an individual sectored channel, as defined 
in table 18.62. 

Table 18.62: Sectored channel detail information element 



Information element 


Length 


Type 


C/O/M 


Remark 


Channel identifier 


4 


1 


M 




Channel characteristics 


18 


1 


M 




Carrier number 


12 


1 


M 




Carrier number extension flag 


1 


1 


M 




Carrier number extension 


10 




C 


See note 1 , 
see note 2. 


NOTE 1 : Shall be present only if carrier number extension flag has value "1" (carrier number extension 

included). 
NOTE 2: If not present, the "Carrier number" element shall fully define the frequency of the channel's 

RF carrier. The channel's extended carrier numbering information shall be assumed to be the 

same as that of the serving cell. 



18.5.22 Subscriber class 

The subscriber class information element shall be used by the SwMI to indicate which subscriber classes are allowed to 
use this cell as defined in table 18.63. 

Table 18.63: Subscriber class information element 



Information element 


Length 


Value 


Remark 


Class 1 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 2 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 3 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 4 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 5 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 6 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 7 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 8 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 9 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Classic 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 1 1 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 12 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 13 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 14 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 15 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 


Class 16 







Subscriber class not allowed on cell 


1 


Subscriber class allowed on cell 
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1 8.5.23 TDMA frame offset 

The TDMA frame offset information element shall indicate the TDMA frame offset between the serving cell and a 
neighbour cell when both cells have synchronized carriers as defined in table 18.64. The element may be used for the 
time-shared mode of operation or to indicate the TDMA frame offset for synchronized cells operating in continuous 
mode. 

Table 18.64: TDMA frame offset information element 



Information element 


Length 


Value 


Remark 


TDMA frame offset 


6 


OOOOOO2 


frame offset 


000001 2 


1 frame offset 


etc. 


etc. 


100011 2 


35 frame offset 


IOOIOO2 


Reserved 


etc. 


etc. 


IIIIII2 


Reserved 



If FNn and FNs denote the TDMA frame number of the neighbour cell and of the serving cell respectively, then: 

FNn = {FNs - 1 + TDMA fi-ame offset)mod 18+1; (18.1) 

where Fnn = 1 to 18 and FNs = 1 to 18. 

1 8.5.24 TETRA network time 

The TETRA network time information element shall indicate the absolute TETRA network time to be used for time 
stamping as defined in table 18.65. 

Table 18.65: TETRA network time information element 



Information element 


Length 


Value 


Remark 


UTC time 


24 




See note 1 


Local time offset sign 


1 




See note 2 


Local time offset 


6 




See notes 2 and 3 


Year 


6 




See note 4 


Reserved 


11 




Note 5 


NOTE 1 : Zero time (OOOOOOie is defined as 00:00 hours, Universal Time Co-ordinates (UTC time) on 

January 1st of every year. 

Each increment of this element above a value of zero shall correspond to a two-second increment 

of the absolute network time. 

The values, F142FFi6 to FFFFFEie, are reserved. 

The value, FFFFFF^e, is reserved and shall be used to indicate an invalid value of time and 

timestamps in the event of network malfunction. 
NOTE 2: The local time offset is coded as a signed integer containing Information elements Local time offset 

sign and Local time offset. The value "0" shall indicate a positive offset and the value "1" shall 

indicate a negative offset. Zero offset shall be encoded with sign value "0". 
NOTE 3: The Local time offset information element shall indicate the difference between the local time 

(including daylight saving) and the UTC time. The step size is 15 minutes, the maximum 

permissible offset shall be ±14 hours. The values 39ie to 3Eie are reserved. 3Fie shall be used to 

indicate an invalid offset. 
NOTE 4: Year is year since 2000 (e.g. year 2001 is encoded as 1). Maximum year value shall be 3Eie. The 

value 3Fi6 shall be used to indicate an invalid year. 
NOTE 5: This field shall be set to all ones (TFFig). 
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18.5.25 Timeshare cell and Al encryption information 

The Timeshare cell and AJ encryption information information element shall indicate the mode of discontinuous 
operation for a neighbour cell and the air-interface encryption as defined in table 18.66. 

The "Discontinuous mode" field shall indicate which of the three types of discontinuous mode is in use. 

If the discontinuous mode is "AI encryption" the usage of the bits comprising the "Reserved frames per two 
multiframes" sub-element shall be as defined in EN 300 392-7 [8]. 

If the mode is "MCCH sharing", the "Reserved frames" sub-element shall indicate how many frames are reserved for 
that neighbour cell. 

If the mode is "Carrier sharing" or "Traffic carrier sharing" sharing, the "Reserved frames" sub-element shall be ignored 
by the MS. 

Table 18.66: Timeshare cell information element 



Information element 


Length 


Value 


Remark 


Discontinuous mode 


2 


OO2 


Al encryption 


OI2 


Carrier sharing 


IO2 


IVICCH sharing 


II2 


Traffic carrier sharing 


Reserved frames per two multiframes (see note) 


3 


OOO2 


1 frame reserved 


OOI2 


2 frames reserved 


01 O2 


3 frames reserved 


OII2 


4 frames reserved 


IOO2 


6 frames reserved 


IOI2 


9 frames reserved 


11 O2 


1 2 frames reserved 


III2 


1 8 frames reserved 


NOTE: If the discontinuous mode is "Al encryption" the information element name shall be as defined in 
EN 300 392-7 [8]. 



18.6 Timers 

18.6.1 Timer related actions 

Timer related actions are defined in the protocols which use the timer. 

1 8.6.2 Timer T370 - cell reselection preparation response time 

This timer shall define the maximum time MLE shall wait for a response to U-PREPARE. The timer, T370, shall be of 
5 s duration. 

18.6.3 Timer T371 - assigned channel replacement preparation response 
time 

This timer shall define the maximum time MLE shall wait for a D-NWRK-BROADCAST EXTENSION PDU in 
response to U-PREPARE. The timer T371 shall be of 5 s duration. 

1 8.6.4 Timer T372 - new channel pause time 

This timer shall define the minimum time MLE shall wait following assignment to a channel before transmitting a first 
U-CHANNEL REQUEST PDU on that channel. The timer T372 shall be of 15 s duration. 
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1 8.6.5 Timer T373 - repeat channel request delay time 

This timer shall define the minimum time MLE shall wait following transmission of a U-CHANNEL REQUEST before 
MLE may transmit a further U-CHANNEL REQUEST PDU. The timer T373 shall be of 5 s duration. 

1 8.6.6 Timer T374 - threshold-crossing pause time 

This timer shall define the minimum time MLE shall wait following the threshold-crossing of an assigned channel 
pathloss measurement before MLE may declare a change in the state of the channel path loss criterion. The timer T374 
shall be of 5 s duration. 
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1 9 Layer 2 overview 
19.1 Introduction 

Clause 19 gives an overview of the V+D air interface layer 2 (Data Link Layer (DLL)) which is further defined in 
clauses 20, 21, 22 and 23. Clause 19 does not imply any requirement for the testability of any of the functions 
described. 

The descriptions throughout clause 19 do not imply a specific implementation, but are provided for the guidance of the 
reader in understanding the operation of layer 2. 



1 9.2 Layer 2 architecture 



The model of the DLL comprises two sub-layers: the LLC entity and the MAC entity. The basic functionalities of these 
entities are as summarized in EN 300 392-1 [6], clause 6, and the services offered to the upper layer (the MLE) are 
explained in detail in clause 20. The error control schemes (FEC, CRC) are described in clause 8. 

The following description applies to the protocol model of the DLL. The internal boundaries between the layers and 
sub-layers are not testable and do not imply any specific implementation, but are rather used for the description of the 
model. Throughout clause 19 the word "shall" is used for describing the SAPs for traceability reasons in the protocol 
model, but those SAPs are not testable. 

19.2.1 Access to the DLL 

Figure 19.1 shows the model of the DLL, its internal subdivision and its interaction with the upper layer (MLE) and 
lower layer (physical layer). 

In the protocol model, the DLL shall provide services to the MLE through SAPs supporting different functions: 

• TLA-SAP for all signalling messages; 

• TLB-SAP for broadcasting system information; and 

• TLC-SAP for layer management, status and configuration via data base access. 

Internal communication between LLC and MAC shall use SAPs, namely TMA-SAP, TMB-SAP and TMC-SAP, for 
services provided by the MAC to the LLC. They shall correspond to the separation between signalling, broadcast and 
layer management, as can be seen from the upper layer (MLE). Internal communication between LLC and MAC may 
also use an additional SAP, namely TLE-SAP, for the layer 2 signalling service that the LLC may provide to the MAC. 
Primitives and parameters are used for protocol description to exchange information at this internal boundary 
(LLC -MAC). The upper MAC layer shall contain MAC protocol functions (see clause 23). 

There shall be a (virtual) SAP TMV-SAP inside the MAC layer to allow a protocol description using primitives and 
logical channels. The selection of a specific logical channel triggers specific channel coding at the lower MAC, which is 
devoted to the channel coding (see clause 8). The selection of a specific logical channel also triggers a specific 
modulation. 

The SAP TP-SAP shall be used for communication between MAC and Physical Layer (PL). To exchange information 
at the TP-SAP, pre-formed subslots and blocks with burst type indication shall be used (see clause 9). 

The TMD-SAP shall be used to support traffic in circuit mode. It shows clearly that no LLC functionality shall be 
expected in circuit mode. However, clause 19.4.3.2 describes how some traffic capacity may be stolen for signalling 
purposes in circuit mode. 
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Figure 19.1 : Layer 2 reference architecture 

19.2.2 Information flow inside the DLL 

The two types of communications links for TLA-SAP support on the DLL each have a specific quaHty of service. 
Before any communication estabHshment, one Hnk shall exist whenever BS control channel monitoring is possible. This 
link is called the basic link and it offers a pre-defined quality of service which minimizes the LLC overhead over the air 
interface. A more powerful link may exist upon request. It is called the advanced link and it offers a more reliable and 
better service, especially for packet data transfer (see clause 22). When an advanced link is established, the basic link 
shall remain available. They may share the same timeslot in the multiframe structure. 

Illustrations of the layer 2 functions applied to the information content present at the TLA-SAP are given on 
figures 19.2 and 19.3. On the left hand side, references to the relevant protocol layers are provided. The "other 
parameters" from the MLE may either be mapped into the LLC PDU or used by the DLL (e.g. PDU priority). 

The advanced link offers segmentation and error control using a Frame Check Sequence (FCS). The advanced link may 
be used for more reliable and efficient exchange of large amount of data as in, for example, packet data transfer. There 
are two variants of advanced link: the original advanced link and the extended advanced link. 

It is mandatory for the MS to support the basic link, whereas it is optional for the MS to support either or both variants 
of the advanced link. 

NOTE 1: The MAC scheme on figures 19.2 and 19.3 does not display the exact multiframe structure nor the 
random access procedure (see clause 23). 

NOTE 2: The CRC is added only to the completed "MAC block", which may contain multiple TM-SDUs (MAC 
messages) on figures 19.2 and 19.3. 
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19.2.2.1 Basic link 



The basic link should be used for general signalling messages (e.g. from the CMCE or MM). The unacknowledged 
basic link may be used by the SNDCP for some packet data messages (e.g. for real-time class data). 

The basic link offers the following services: 

• acknowledged message transmission; 

• unacknowledged message transmission; 

• un-numbered fragmentation of longer messages; 

• optional extended error control using an PCS (e.g. for long messages that require fragmentation). 

The principal basic link data structure without fragmentation is shown in figure 19.2. The protocol is defined in detail in 
clauses 22 and 23. 

19.2.2.2 Advancedlink 

An advanced link should be used if a larger amount of data is to be transferred (e.g. for packet data transmission) or if a 
better service is required. The service of an advanced link is negotiable at the set-up phase. The advanced link offers the 
following services: 

• acknowledged message transmission; 

• unacknowledged message transmission for point-to-multipoint transfer in the downlink; 

• window mechanism: 

window size of up to 3 for the original advanced link; 
window size of up to 15 for the extended advanced link; 

• numbered segmentation of longer messages; 

• selective re-transmission for point-to-point transfer; 

• selective re-assembly for point-to-multipoint transfer; 

• extended error control using an PCS 

always provided for the original advanced link; 
optional for the extended advanced link. 
The advanced link data structure is shown in figure 19.3. The protocol is defined in detail in clauses 22 and 23. 

19.2.2.3 Segmentation and fragmentation 

There are two methods of sending a long TL-SDU defined in the present document: fragmentation and segmentation, 
which are defined in detail in clauses 22 and 23. Pragmentation may be performed in the MAC for a basic link, while 
segmentation may be performed in the LLC for an advanced link (see figure 19.4). 

Pragmentation shall be used for the basic link in case of an SDU exceeding the available capacity in the MAC (see 
figure 19.5). Pragments are not numbered so they shall be sent in sequence. No segmentation shall be performed by the 
LLC for the basic link. 
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Figure 19.4: Segmentation and fragmentation in the DLL 
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Figure 19.5: Fragmentation of long SDU in the IVIAC layer 

For the advanced link, the LLC shall divide long data into segments (see figure 19.3). Each segment shall be 
individually recognizable by its LLC header. The segment size depends on the modulation mode of the channel 
(see clause 19.3.2.2). 

• On a 3I/4-DQPSK or D8PSK channel, the segment size should match the MAC transmission unit (MAC 
block). Therefore, on a D8PSK channel, segments may be of different sizes, depending on whether they are 
cut to be sent using 7i/4-DQPSK or 71/8-D8PSK modulation for the first transmission of that segment. 

• On a 25 kHz or 50 kHz QAM channel, the segment size is normally determined by the available space in a 
full-slot MAC block using 4-QAM with coding rate r = V2 at the current RF bandwidth; on a 100 kHz or 
150 kHz QAM channel, the segment size is normally determined by the available space in half of a full-slot 
MAC block using 4-QAM with coding rate r = V2 at the current RF bandwidth. The first and last segment of a 
TL-SDU may be of different size. 

The segment is defined as the unit of re-transmission. Therefore: 

• on a 7I/4-DQPSK channel, fragmentation should not be used for advanced link messages; 

• on a D8PSK channel, fragmentation is needed when a segment cut for transmission using 71/8-D8PSK 
modulation is re-transmitted using 7i/4-DQPSK modulation; 

• on a QAM channel, fragmentation should not normally be used for advanced link messages (except for 
re-transmissions after a reduction of the RF bandwidth). 

Use of these segment sizes on a QAM channel means that, on a 25 kHz or 50 kHz QAM channel: 

• a full slot using 4-QAM with coding rate r = V2 can contain one advanced link segment; 

• a full slot using 16-QAM with coding rate r = V2 can contain two advanced link segments; 

• a full slot using 16-QAM with coding rate r = 1 can contain four advanced link segments; 

• a full slot using 64-QAM with coding rate r = V2 can contain three advanced link segments; 
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• a fall slot using 64-QAM with coding rate r = % can contain four advanced link segments; 

• a full slot using 64-QAM with coding rate r = 1 can contain six advanced link segments. 

This is illustrated in figure 19.6. Choice of the segment size corresponding to the smallest full-slot MAC block size 
(i.e. 4-QAM with coding rate r = 1/2) enables segments to be re-transmitted without fragmentation even if the 
modulation level and/or coding rate is changed. 

NOTE: The same principle applies on a 100 kHz or 150 kHz QAM channel except that the segment size 

corresponds to half the size of the smallest full-slot MAC block, so that segments do not become too 
large. 
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NOTE: In this figure, M represents IVIAC header and L represents LLC header. 

Figure 19.6: Advanced link segments on a 25 l<l-lz or 50 ItlHz QAIU! chiannel 

1 9.2.2.4 Layer 2 signalling 

In addition to the basic link and advanced link, the LLC may send and receive layer 2 signalling PDUs; these PDUs 
carry various types of general signalling information relating to layer 2 functions. The layer 2 functions may be either 
LLC or MAC functions. However, for the purposes of the data exchange mechanisms, the layer 2 signalling PDUs are 
treated as LLC PDUs. 

The layer 2 signalling offers the following services: 

• unacknowledged message transmission; 

• un-numbered fragmentation of longer messages. 
The current uses of layer 2 signalling are: 

• for the MAC in the MS to indicate short-term variations in the MS's required data priority (temporarily 
modifying the default data priority negotiated with the SwMl by the SNDCP); 

• for the BS to send schedule synchronization information; and 

• for the MAC in the MS and BS to send link adaptation feedback information on a D8PSK or QAM channel. 
Link adaptation feedback from the MS may aid the BS in its choice of the appropriate modulation (and coding 
rate for QAM) to use for transmission to that MS; link adaptation feedback from the BS may aid the MS in its 
choice of the appropriate modulation (and coding rate for QAM) to use for transmission; see clause 19.3.2.2. 

Where a layer 2 signalling PDU relates to a MAC function, the LLC provides the layer 2 signalling service to the MAC 
through the TLB-SAP. 
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When the LLC sends or receives a layer 2 signalling PDU (relating to either an LLC or MAC function), it uses the data 
transfer service primitives offered by the MAC at the TMA-SAP. 

19.2.3 Sub-layers 

A detailed DLL illustration for peer-to-peer information exchange is presented in figure 19.7. The path followed by the 
information flow is shown from the C-plane SAPs - namely TLA and TLB. Information shall enter the MAC through 
the corresponding TMA and TMB SAP. The U-Plane information shall enter the MAC directly through the TMD-SAP. 
In either case, by using the TMV-SAP service primitive, the information shall then be placed into the appropriate 
logical channel and transmitted to the physical layer on the assigned timeslot in the multiframe. 

NOTE 1 : Layer 2 signalling is not used in this illustration so, for clarity, the TLE-S AP is not shown. 
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Figure 19.7: DLL protocol illustration for the MS side for tt/4-DQPSK operation 

The information for layer management flows through the TLC-SAP to the LLC and MAC and further down to the 
physical layer. 

In figure 19.7 an example is shown in which some LLC links (numbered from 1 to 4) are set up on the MS side. 

NOTE 2: In figure 19.7 three links are considered as a possible scenario, but it is not mandatory for an MS to 
support multiple links. 

Link 1 uses the timeslot 1 in the multiframe structure in the upper MAC. Timeslot 1 is used for traffic coming from the 
TMD-SAP. The first occurrence of this traffic is stolen by link 1 . Link 2 is used to send a signalling message in the 
uplink on timeslot 3 (in this example a set-up of an advanced link). After that message exchange, link 4 is the newly 
set-up advanced link using timeslots 3 and 4 to increase the throughput. Finally, some broadcast information are 
received under the TxB-SAP in timeslots 1 and 2 of the last shown frame. 



£75/ 



504 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

The various logical channels involved in this communication exchange are shown at the TMV-SAP. At the lower MAC, 
a specific channel coding is applied for each of them. All information in the MAC not related to layer management shall 
be exchanged to/from the physical layer through the TP-SAP. 

Each sub-layer should contain its own layer management. 

19.2.3.1 LLC sub-layer 

The LLC shall deal with the LLC link establishment and maintenance for the C-plane under the TLA-SAP. From the 
MLE point of view, there may be multiple LLC instances, each dealing with a specific quality of service and identified 
by a number corresponding to the link identifier, see figure 19.7. The basic link shall be available when the MS has 
synchronized to the BS. In addition to the basic link, the MLE may request a higher quality of service from the LLC, 
and the LLC then may set up an advanced link or links as required depending on the capabilities of the MS. Each 
advanced link normally uses a fixed resource at the MAC layer, which may be shared by a basic link. 

The number of simultaneous links in an MS depends on its capability. The MS may have up to four independent 
advanced links per service (i.e. acknowledged service or unacknowledged service) as either: 

• one original advanced link per service plus up to three extended advanced links per service; or 

• up to four extended advanced links per service. 

If the MS has multiple simultaneous advanced links, some or all of the advanced links may share the same resource at 
the MAC layer, in which case there is only one basic link associated with those advanced links. Alternatively, the 
advanced links may use different resources at the MAC layer, in which case up to four basic links may be associated 
with the corresponding advanced links. (Scanning a different frequency or cell in search for a control channel uses a 
different link.) 

Under the TLB-SAP, there is no LLC functionality and the MLE SDU is passed directly to/from the TMB-SAP. 
Therefore, peer-to-peer information exchange between LLC entities does not exist and there exists no LLC PDU for the 
broadcast under the TLB-SAP. 

The TLC-SAP shall be used for layer management and layer-to-layer control communication. 

19.2.3.2 MAC sub-layer 

The main functionalities of the MAC are channel access control, radio resource control, data transfer and error 
detection, and also link adaptation on a D8PSK or QAM channel. Encryption over the air interface shall be performed 
in the upper MAC when required. 

The LLC links defined at the TLA-SAP shall enter into the MAC using the TMA-SAP. Logical channel allocation and 
multiplexing shall be performed internally by the MAC. From the protocol point of view, the upper MAC shall 
communicate with the lower MAC by means of primitives through logical channels. From the architecture point of 
view, the choice of the logical channels permits selecting among different means of data protection (channel coding) 
and modulation which are part of the lower MAC and physical layer. 

After the set-up of a circuit mode speech or data call, signalling messages may use the Associated Control Channel 
(ACCH) or may use the traffic channel stealing mechanism (Stealing Channel STCH). 

Figure 19.7 illustrates how signalling from the LLC link 1 shares a timeslot with user traffic from U-plane by stealing 
and using the STCH logical channel. The user plane traffic uses the TCH logical channel. The broadcast information 
flowing via TMB-SAP may use specific BSCH logical channel or signalling logical channel SCH. The MAC layer 
allocates 2 timeslots (2 x SCH) for the LLC instance 4 using an advanced link providing a higher transfer rate. All 
logical channels are then encoded at the lower MAC layer as defined by the logical channel (refer to clause 8). 
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19.2.4 Logical channels 

1 9.2.4.1 Logical channels at the LLC-SAP 

The MLE communicates to the LLC by using the relevant SAPs. Multiple LLC instances may be seen through the 
TLA-SAP. The MLE may choose to send a request on any available link, taking into account the associated quality of 
service. 

Also the MAC communicates to the LLC through the TLE-SAP for the layer 2 signalling service. 

1 9.2.4.2 Logical channels at the MAC-SAP 

The LLC and U-plane shall communicate with the MAC via the relevant SAPs. The TMA-SAP shall be used for 
signalling, the TMB-SAP shall be used for downlink broadcast, the TMC-SAP shall be used for layer management and 
the TMD-SAP shall be used for circuit mode traffic and user signalling. 

19.2.4.3 MAC internal logical channels 

The logical channels may be separated into two categories: 

1) traffic channels carrying U-plane information (circuit mode data and voice) plus end-to-end user signalling 
information; these shall carry information which is exchanged via the TMD-SAP at the MAC boundary; 

2) control channels carrying C-plane information (control messages and packet data); these shall carry 
information which is exchanged via the TMA- and TMB-SAP at the boundary between MAC and LLC. 

The following logical channels are defined within the upper MAC: 

• Control Channel comprising: 

Main Control Channel (MCCH); 

Common Secondary Control Channel (Common SCCH); 

Assigned Secondary Control Channel (Assigned SCCH). 

These channels shall carry control information appearing at the TMA-SAP addressed to MS(s) not involved in 
a circuit mode call. Refer to clause 23. 

• Associated Control Channel (ACCH) comprising: 

Fast Associated Control Channel (FACCH); 

SteaUng Channel (STCH); 

(Slow) Associated Control Channel ((S)ACCH). 

These channels shall carry control information appearing at the TMA-SAP intended for MS(s) involved in a 
circuit mode call. 

• Broadcast Common Control Channel (BCCH) comprising: 

Broadcast Synchronization Channel (BSCH); 
Broadcast Network Channel (BNCH or BNCH-Q). 
These channels shall carry the system broadcast information appearing at the TMB-SAP. 
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1 9.2.4 A Logical channels at the lower MAC 

Logical channels shall offer different physical paths to the information depending on the chosen error control scheme 
among those defined in clause 8. 

The following generic logical channels shall be available at the lower MAC boundary for phase modulation (see 
figures 19.8 and 19.9): 

Access Assignment Channel (AACH); 

Broadcast Synchronization Channel (BSCH); 

SignalHng Channel (SCH); 

Traffic Channel (TCH); 

Stealing Channel (STCH); 

Common Linearization Channel (CLCH). 

The following generic logical channels shall be available at the lower MAC boundary for QAM (see figures 19.10 
and 19.11): 

• QAM Access Assignment Channel (AACH-Q); 

• QAM Slot Information Channel (SICH-Q/D or SICH-Q/U); 

• QAM Signalling Channel (SCH-Q); 

• QAM Common Linearization Channel (CLCH-Q). 

As far as possible, the present document avoids defining specific physical architectures, but proposes instead to explain 
operation of the MAC sub-layer in terms of the functional blocks and logical channels. This reference model 
architecture applies equally to MSs and BSs. MSs transmission and reception for phase modulation are shown in 
figures 19.8 and 19.9 respectively. MSs transmission and reception for QAM are shown in figures 19.10 and 19.1 1 
respectively. 

NOTE: The only SAPs shown on these figures are the upper MAC, lower MAC and physical layer SAPs. The 
TLE-SAP, through which the LLC may provide a layer 2 signalling service to the MAC, is not shown. 
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Figure 19.8: MAC sub-layers and logical channels for MS uplink transmission 

using phase modulation 
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Figure 19.9: MAC sub-layers and logical channels for MS downlink reception using phase modulation 



£75/ 



508 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



LLC 



U-Plane 



TMC-SAP 



TMA-SAP 



TMD-SAP 



UPPER MAC 



CLCH-Q SICH-Q/U SCH-Q 



TMV-SAP 



LOWER MAC 



TPC-SAP 



LB 



'TL 



RAB 



CB 



NUB 



TP-SAP 



PHYSICAL LAYER 



Figure 19.10: MAC sub-layers and logical channels for IVIS uplink transmission using QAM 
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Figure 19.11 : MAC sub-layers and logical channels for MS downlink reception using QAM 

Tables 19.1, 19.2, 19.3 and 19.4 provide a summary of the logical channels shown in figures 19.8, 19.9, 19.10 

and 19.1 1. The information mapping on these logical channels is presented starting with the MAC layer SAPs down to 

the physical bursts and blocks. 
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Table 19.1 : Mapping between TMx-SAP and MAC logical channels for phase modulation 



SAP 


Definition 


Logical 
channel in 
TMV-SAP 


Definition 
(see note) 


IMA 


main control channel or 

tt/4-DQPSK secondary control channel 


SCH/F 

SCH/HD 

SCH/HU 


signalling channel (full slot) 
signalling channel (1/2 slot downlink) 
signalling channel (1/2 slot uplink) 


D8PSK control channel 


SCH/F 

SCH/HD 

SCH/HU 

SCH-P8/F 

SCH-P8/HD 

SCH-P8/HU 


signalling channel (full slot) 
signalling channel (1/2 slot downlink) 
signalling channel (1/2 slot uplink) 
signalling channel (tt/8-D8PSK full slot) 
signalling channel (tt/8-D8PSK 1/2 slot downlink) 
signalling channel (tt/8-D8PSK 1/2 slot uplink) 


fast associated control channel or 
slow associated control channel 


SCH/F 

SCH/HD 

SCH/HU 


signalling channel (full slot) 
signalling channel (1/2 slot downlink) 
signalling channel (1/2 slot uplink) 


stealing channel (signalling) 


SIGH 


stealing channel (signalling) 


TMD 


traffic channel (circuit mode) 


TCH 


traffic channel (circuit mode) 


stealing channel (user signalling) 


STCH 


stealing channel (user signalling) 


TMB 


broadcast synchronization channel 


BSCH 


broadcast synchronization channel 


broadcast network channel 


BNCH on 
SCH/HD or 
SCH-P8/F or 
SCH-P8/HD 


signalling channel (1/2 slot downlink) 
signalling channel (tt/8-D8PSK full slot) 
signalling channel (tt/8-D8PSK 1/2 slot downlink) 


- 


access assignment channel 
(generated inside the upper MAC) 


AACH 


access assignment channel 


- 


common linearization channel 
(generated inside the upper IVIAC) 


CLCH 


common linearization channel 


NOTE: Signalling uses tt/4-DQPSK modulation unless stated otherwise. 



Table 19.2: Mapping between MAC logical channels and physical layer bursts for phase modulation 



Logical 
channel in 
TMV-SAP 


Definition 
(see notel) 


Physical burst 
(see note 2) 


Definition 
(see note 2) 


SCH/F 


full slot signalling channel 


NDB, 
NUB 


normal downlink burst, 
normal uplink burst 


SCH/HD 


half slot downlink signalling channel 


NDB + SF 
BKN2 of SB 


normal downlink burst and slot flag 
2nd half of synchronization burst 


SCH/HU 


half slot uplink signalling channel 


CB 


control uplink burst 


SCH-P8/F 


TT/8-D8PSK full slot signalling channel 


TT/8-D8PSK NDB, 
TT/8-D8PSK NUB 


TT/8-D8PSK normal downlink burst, 
TT/8-D8PSK normal uplink burst 


SCH-P8/HD 


TT/8-D8PSK half slot downlink signalling 
channel 


TT/8-D8PSK NDB + SF 


TT/8-D8PSK normal downlink burst and 
slot flag 


SCH-P8/HU 


TT/8-D8PSK half slot uplink signalling 
channel 


TT/8-D8PSK CB 


TT/8-D8PSK control uplink burst 


STCH 


stealing channel 


NDB + SF, 
NUB + SF 


normal downlink burst and slot flag, 
normal uplink burst and slot flag 


TCH 


traffic channel 


NDB, 
NUB 


normal downlink burst, 
normal uplink burst 


BSCH 


broadcast synchronization channel 


SB 


synchronization burst 


AACH 


access assignment channel 


BBK (see note 3) 


broadcast block 


CLCH 


common linearization channel 


LB 


linearization burst 


NOTE 1 : Signalling uses tt/4-DQPSK modulation unless stated otherwise. 
NOTE 2: Physical bursts are tt/4-DOPSK bursts unless stated otherwise. 

NOTE 3: The AACH is transmitted using tt/4-DOPSK modulation. (Thus, on a D8PSK channel, the AACH is 
transmitted using tt/4-DQPSK modulation in both tt/4-DOPSK and tt/8-D8PSK downlink bursts.) 
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Table 19.3: Mapping between TMx-SAP and MAC logical channels for QAM 



SAP 


Definition 


Logical 
channel in 
TMV-SAP 


Definition 


IMA 


QAM control channel 


SCH-Q/D 
SCH-Q/U 
SCH-Q/HU 
SCH-Q/RA 


QAM signalling channel (full slot downlink) 
QAM signalling channel (full slot uplink) 
QAM signalling channel (1/2 slot uplink) 
QAM signalling channel (random access) 


TMB 


QAM broadcast network channel 


BNCH-Qon 
SCH-Q/D 


QAM signalling channel (full slot downlink) 


- 


QAM access assignment channel 
(generated inside the upper MAC) 


AACH-Q 


QAM access assignment channel 


- 


QAM slot information channel 
(generated inside the upper MAC) 


SICH-Q/D 
SICH-Q/U 


QAM slot information channel (downlink) 
QAM slot information channel (uplink) 


- 


QAM common linearization channel 
(generated inside the upper MAC) 


CLCH-Q 


QAM common linearization channel 



Table 19.4: Mapping between MAC logical channels and physical layer bursts for QAM 



Logical 
channel in 
TMV-SAP 


Definition 


QAM physical burst 


Definition 


SCH-Q/D 


QAM full slot downlink signalling channel 


NDB 


QAM normal downlink burst 


SCH-Q/U 


QAM full slot uplink signalling channel 


NUB 


QAM normal uplink burst 


SCH-Q/HU 


QAM half slot uplink signalling channel 


CB 


QAM control uplink burst 


SCH-Q/RA 


QAM random access signalling channel 


RAB 


QAM random access uplink burst 


AACH-Q 


QAM access assignment channel 


Transmitted in the 
header symbols within 
the NDB 


Transmitted in the header symbols 
within the QAM normal downlink 
burst 


SICH-Q/D 


QAM downlink slot information channel 


Transmitted in the 
header symbols within 
the NDB 


Transmitted in the header symbols 
within the QAM normal downlink 
burst 


SICH-Q/U 


QAM uplink slot information channel 


Transmitted in the 
header symbols within 
the NUB and CB 


Transmitted in the header symbols 
within the QAM normal uplink 
burst and QAM control uplink burst 


CLCH-Q 


QAM common linearization channel 


LB 


QAM linearization burst 



1 9.2.5 Lower layer management at the DLL 



The TETRA protocol architecture, EN 300 392-1 [6], clause 6 shows how the lower layer management entity is 
incorporated into all lower layers and is accessible via SAPs TxC-SAP as shown in figures 19.1 and 19.7 for the lowest 
layers. Those access points enable access to information such as measured values, status, general information. The 
services related to the management of LLC and MAC are described in clause 20. 

The DLL should have its own set of functions and measured values. These parameters shall be exchanged using a set of 
primitives as described in the appropriate clause, namely clauses 22 and 23. 

19.3 System modes of operation 

Clauses 19.3.1 to 19.3.6 provide an outline description of system modes of operation and their impact on layer 2. 

19.3.1 Normal mode 

In the normal mode of operation, the common control channel on the main carrier shall always be the MCCH and shall 
always be present in timeslot 1 of all frames 1 to 18. This common control channel shall be used for all common control 
signalling. All MSs shall be able to locate and listen to the downlink transmissions of the MCCH. The BS shall transmit 
on all downlink slots of the main carrier during normal mode. 
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19.3.2 Extended mode 

19.3.2.1 General 

A BS may have more than one control channel (common or assigned) operational at a time. The ways to operate this 
may be as follows: 

• in addition to MCCH, BS may have from one to three common SCCH, which has the same functionality as the 
MCCH but may be used only by a sub-set of the user population; 

• in addition to MCCH, BS may have one or several assigned SCCHs used to continue control signalling and 
packet mode signalling after the initial random access or paging message; 

• in minimum mode (without MCCH), BS may have one or several assigned SCCHs used to continue control 
and packet mode signalling after the initial random access or paging message; 

• in addition to MCCH, BS may have from one to three common SCCH and one or several assigned SCCHs 
used to continue control and packet mode signalling after the initial random access or paging message. 

The MCCH and common SCCHs cannot be extended to more than one timeslot per TDMA frame. The MCCH and 
common SCCHs are 7i/4-DQPSK channels. 

Assigned SCCH can be from one up to four timeslots per TDMA frame. An assigned SCCH may be allocated as a 
7I/4-DQPSK, D8PSK or QAM channel (see clause 19.3.2.2). 

Common SCCHs shall be in the same carrier as the MCCH. Assigned SCCHs may be allocated from any carrier. 

NOTE: The extended mode does not necessarily increase the control channel capacity of an individual MS; only a 
multislot or D8PSK or QAM assigned SCCH provides a higher transfer rate. 

19.3.2.2 Modulation modes 

There are three possible modulation modes for channels: 7i/4-DQPSK, D8PSK and QAM. The signalling operation with 
the three modulation modes is outlined in clauses 19.3.2.2.1, 19.3.2.2.2 and 19.3.2.2.3. 

19.3.2.2.1 TT/4-DQPSK channel 

All signalling and data messages and traffic on a 7i/4-DQPSK channel are sent using 7i/4-DQPSK modulation. 
The RF bandwidth of a 7i/4-DQPSK channel is 25 kHz. 

19.3.2.2.2 D8PSK channel 

A "D8PSK channel" is the generic term for a channel on which signalling and data messages may be sent using either 
7I/4-DQPSK bursts or 71/8-D8PSK bursts. The transmitting BS or MS chooses whether to use a 7i/4-DQPSK burst or a 
71/8-D8PSK burst on a slot-by-slot basis. The receiving MS or BS determines whether a slot (or subslot) contains 
a 7I/4-DQPSK burst or a 71/8-D8PSK burst by determining whether the training sequence uses the 7i/4-DQPSK form or 
the 7I/8-D8PSK form. 

The RF bandwidth of a D8PSK channel is 25 kHz. 

19.3.2.2.3 QAM channel 

All signalling and data messages on a QAM channel are sent using QAM modulation. The transmitting BS or MS 
chooses which modulation level and coding rate to use on a slot-by-slot basis. There are six valid combinations: 

• 4-QAM, coding rate r = 1/2; 

• 16-QAM, coding rate r = 1/2 or 1 ; 

• 64-QAM, coding rate r = 1/2, 2/3, or 1 . 
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The access assignment channel AACH-Q (in a QAM normal downlink burst), and the slot information channels 
SICH-Q/D (in a QAM normal downlink burst) and SICH-Q/U (in a QAM normal uplink burst or QAM control uplink 
burst), always use 4-QAM with coding rate r = Vi. The slot information channels SICH-Q/D and SICH-Q/U indicate the 
modulation and coding rate used in the remainder of the slot or subslot. 

The RF bandwidth of a QAM channel may be 25 kHz, 50 kHz, 100 kHz or 150 kHz. 

The random access burst always uses 4-QAM, coding rate r = Vi with a 25 kHz bandwidth - irrespective of the RF 
bandwidth of the QAM channel. For the purposes of the random access procedure, each subslot (i.e. half slot) that is 
available for random access is divided into 25 kHz frequency blocks. This provides 2, 4 or 6 parallel "random access 
uplink RF channel subslots" within a single subslot on a 50 kHz, 100 kHz or 150 kHz channel respectively. 

19.3.3 Minimum mode 

Minimum mode allows a BS to assign all four timeslots on the main carrier for traffic or dedicated control purpose. In 
this mode, only frame 18 can be used for common control without disturbing the established services. A BS enters 
minimum mode when all four downlink timeslots on the main carrier are assigned so that there is no common control 
channel available in timeslot 1 . 

19.3.4 Discontinuous transmission mode 

A BS may transmit discontinuously on the main carrier when it operates in one of the following time sharing modes. 



19.3.5 Time sinaring mode 

In the time shared mode, multiple BSs may use the same radio resource for control channel purposes in a co-ordinated 
manner. 

1 9.3.5.1 Carrier sharing mode 

In carrier sharing mode, one carrier frequency used for phase modulation shall be shared among up to four cells, each 
cell being allocated at least one timeslot of the TDMA frame (see clause 9 for more details). 

19.3.5.2 MCCH sharing mode 

In the MCCH sharing mode, the MCCH shall be shared among several cells in a manner under the control of the 
infrastructure (see clause 9 for more details). 

19.3.6 No service mode 

A BS may be in a mode where it is not able to provide any services. In this mode, the BS may transmit unallocated 
physical channel (UP) on all of the timeslots of its main carrier. 

A BS should also set the "BS Service Details" information element of the D-MLE-SYSINFO PDU to OOOOOOOOOOOO2, 
to further indicate that the BS does not provide any TETRA services in this mode. 

NOTE: A BS that is in this mode is not in normal mode. 

1 9.4 MS modes of operation 
19.4.1 Idle mode 

The idle mode shall be the state of the registered MS not involved in any particular transmission. It shall consist of 
listening to the MCCH or to any signalling channel the MS could have been told by the SwMI. The MS shall be capable 
of monitoring adjacent cell in this mode as described in clause 23. 



£75/ 



51 3 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

19.4.2 Signalling and packet mode 

19.4.2.1 Common control channel 

This channel shall support common signalling for all MSs (see clause 23). In a system, there may be in addition to the 
MCCH one or more SCCHs. By default, the MS shall listen to the MCCH for paging and other signalling (see 
clause 19.4.5 for energy economy). 

1 9.4.2.2 Secondary control channels 

These channels shall be used to increase the capacity of the common control channel. They may have the same 
functionality as the MCCH for a subdivision of the population or they may be devoted to support only certain type of 
transmission, e.g. packet mode data. In that respect, they may serve as a control channel dedicated to packet data 
transmission (see clause 23). The BS shall command MS to use appropriate control channel by allocating additional 
resources or by commanding MS to go to a certain control channel (refer to clause 19.3.2). The BS shall command MS 
to use the appropriate control channel, either by a broadcast message indicating the number and location of common 
SCCHs in operation, or by commanding certain MS to go to an assigned SCCH. 

An assigned SCCH may be allocated as a 7i/4-DQPSK, D8PSK or QAM channel. It is optional for the MS or BS to 
support D8PSK and/or QAM channels. 

NOTE: A BS could use an assigned SCCH for continuing signalling for circuit mode call set-up. 

The BS may decide to assign an SCCH for advanced link packet data transmission. There are different 
possible methods of usage. 

EXAMPLE: a) the BS may use an assigned SCCH for only one advanced link (i.e. similar to the usage of a 

channel for a circuit mode call); or 
b) the BS may use an assigned SCCH as a general packet data channel, supporting advanced links 
for many MSs, where each MS may be offering/receiving data packets at a low rate or 
intermittently. 

MS operation is the same in both cases. The channel usage is scheduled by the BS; and MSs 
transmit only under BS control (by random access or reserved access). When appropriate, an MS 
may be permitted to remain on the channel while its advanced link is connected, even though the 
MS is not necessarily using the link all the time. After a pause, the MS uses random access when it 
wishes to continue transmission. 

An advanced link can also use a common control channel or, for MSs in a circuit mode call, an 
ACCH. However, if common control channel, the normal control channel performance may be 
degraded. 

1 9.4.2.3 Associated Control Channel (ACCH) 

This channel shall be used for signalling in conjunction with an established circuit (traffic channel). That signalling may 
be independent of the call the control channel is associated with. The lower MAC should be configured as shown in 
figure 19.12. Depending on the circuit mode call type and the capabilities of MS, the ACCH maybe available during 
timeslots in frames 1 to 18 (if they are not being used for traffic), and it is always available during the 18th frame; refer 
to clause 23. The first one is called Fast Associated Control Channel (FACCH) (frames 1 to 18) and the latter Slow 
Associated Control Channel (SACCH) (frame 18). The MS shall listen to the ACCH under control of the BS; refer to 
clause 19.4.4. 

Circuit mode traffic transmissions apply only on 7i/4-DQPSK channels. Therefore signalling on the ACCH is sent using 
7I/4-DQPSK modulation. 
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19.4.2.4 Full and half slot signalling 

1 9.4.2.4.1 Full and half slot signalling on a tt/4-DQPSK channel 

In figures 19.12 and 19.13, full slot (SF = 0) or half slot (SF = 1) downlink signalling shall be indicated by the 
appropriate slot flag (SF). The slot flag (SF) shall be a change between two training sequences, as described in clause 9. 
Downlink control messages may usually occupy a full slot, but the system Broadcast channels (BxCH) shall be all one 
half slot long to enable them to be transmitted in frame 18 (BSCH or SCH/HD; see clause 9). 

For the MS transmission on the uplink for initial access, a subslot is used - corresponding to the logical channel 
SCH/HU as described in clause 9. 

Uplink control messages are usually sent within a subslot using the logical channel SCH/HU. However, for packet data 
or when using fragmentation, the MS may need to use reserved full slots or subslots for the transmissions subsequent to 
the initial access. The allocation of MS reserved uplink slots and subslots shall be under the control of the BS. 

Once the MS has switched into traffic mode, all transmissions shall be done over an entire timeslot. Distinction between 
full slot for traffic and half slot to indicate that the first half slot has been stolen for signalling purposes shall be 
indicated by a change between the two training sequence, in a manner identical to that used for the downlink. 
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Figure 19.12: Configuration in signalling and packet mode on a tt/4-DQPSK channel 
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1 9.4.2.4.2 Full and half slot signalling on a D8PSK channel 

For downlink signalling on a D8PSK channel, full slot (SF = 0) or half slot (SF =1) downlink signalling shall be 
indicated by the appropriate Slot Flag (SF). The slot flag (SF) shall be a change between two training sequences, as 
described in clause 9. The training sequence also indicates whether the slot contains a 7i/4-DQPSK normal downlink 
burst or a 31/8-D8PSK normal downlink burst. Thus there are four possible normal training sequences in a downlink slot 
on a D8PSK channel. (A further training sequence is used for the synchronization downlink burst.) 

For the MS transmission on the uplink for initial access, a 7i/4-DQPSK subslot is used - corresponding to the logical 
channel SCH/HU as described in clause 9. 

Subsequent to the initial access, the MS may need to use full slots or subslots, reserved for that MS by the BS. Either a 
7I/4-DQPSK or 31/8-D8PSK normal uplink burst may be used in a reserved slot - corresponding to logical channel 
SCH/F or SCH-P8/F. Either a 7i/4-DQPSK or 71/8-D8PSK control uplink burst may be used in a reserved subslot - 
corresponding to logical channel SCH/HU or SCH-P8/HU. For both reserved slots and subslots, the training sequence 
indicates the modulation of the burst. 

1 9.4.2.4.3 Full and half slot signalling on a QAM channel 

Full slot signalling is used on the downlink of a QAM channel - corresponding to logical channel SCH-Q/D. This uses 
the full RF bandwidth of the QAM channel. The BS chooses which modulation level and coding rate to use on a 
slot-by-slot basis. 

For the MS transmission on the uplink for initial access, a random access uplink RF channel subslot is used - 
corresponding to the logical channel SCH/RA as described in clause 9. The random access transmission uses a 25 kHz 
bandwidth, irrespective of the RF bandwidth of the QAM channel, and always uses 4-QAM, coding rate r = 1/2. 

Subsequent to the initial access, the MS may need to use full slots or subslots, reserved for that MS by the BS - 
corresponding to the logical channel SCH-Q/U for a full slot or SCH-Q/HU for a reserved subslot. These use the full RF 
bandwidth of the QAM channel. The transmitting MS chooses which modulation level and coding rate to use in each 
slot or subslot. 
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19.4.3 Traffic mode 

Traffic mode applies only on 3i/4-DQPSK channels. 

19.4.3.1 Normal operation 

The traffic mode may be either speech or data circuit operation. The logical channels in use shall be TCH (traffic 
channels) for frames 1 to 17. Full slots (Slot Flag = 0) shall normally be used for traffic. Frame 18 shall be used for 
signalling only. 
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Figure 19.13: Configuration in traffic mode for frames 1 to 17 on a n/4-DQPSK channel 
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19.4.3.2 stealing mechanism 

When in traffic mode (either speech or data circuit), capacity may be stolen for signalling purposes. This shall leave the 
current mode of operation unchanged. The appearance of half slot (SF = 1) in the transmission shall indicate that 
stealing has occurred. Half slot (SF =1) operation shall be indicated by a change in the appropriate training sequence as 
described in clause 9. The MAC header of the first half of the slot shall indicate whether the other half has also been 
stolen or if it belongs to the normal traffic circuit. The MAC header shall contain an information on the intended 
destination of the signalling message: either C-plane or U-plane signalling. Stealing occurrence shall be locally reported 
to the U-plane application at the TMD-SAP (see figure 19.13). 

This mechanism shall apply to both BS and MS transmissions. 

1 9.4.4 Selection of the mode of operation 

During a transaction on a 7i/4-DQPSK channel, the MAC shall be considered to be switched into one of the following 
modes of operation: 

• signalling mode; or 

• traffic mode. 

The selection mechanism is presented in figure 19.14. The default mode of the MAC layer shall be signalling mode 
(selector in position 1 on figure 19.14). The BS shall send CC messages to change the mode of operation in the MS 
MAC layer. This change shall be reflected from the CC into the MAC using layer management communication internal 
to the MS. In case of accidental loss of the CC message, a fall-back mechanism is specified using the AACH 
indications. 

When stealing is initiated in circuit mode operation (either by the MS or the SwMI), the logical channel shall be 
temporarily taken (fully or partially) on a half slot by half slot basis for signalling purposes. 



BSCH 
60 bits 



AACH 
14 bits 



SCH/F 
268 bits 



SCH/HD 
124 bits 



SCH/HU 
92 bits 



Signalling and 
Pacl<et mode Data 



(signalling 
mode) 



TCH/7,2 



TCH/S 



STCH 
124 bits 



TCH/4,8 
TCH/2,4 



STCH 
124 bits 



Circuit mode 
Speech 



Circuit mode 
Data 



(traffic mode) 



(default position) 



\ 



SELECTOR (controlled 
by SwMI) 



Figure 19.14: Selection of configuration for thie current mode of operation on a tt/4-DQPSK chiannel 

If traffic mode is selected, then the mode selector switch shall be considered to be set accordingly in the MS and in the 
SwMI. 

In case of independent uplink and downlink assignment (e.g. to cover inter-site calls), the selector may be duplicated for 
uplink and downlink operation (i.e. for MS transmission and reception). Still, the selectors shall be set accordingly in 
the MS and SwMI. 

NOTE: Traffic mode applies only to frames 1 to 17. Both MS and BS are in signalling mode on frame 18. 
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1 9.4.5 Energy economy mode 



On the MS request, the BS MM may command the MS to energy economy mode on the MCCH or a common SCCH. 
The start of the energy economy shall be indicated by the BS. The MS shall then follow a regular cycle of N timeslots 
in energy economy for 1 timeslot in reception. During energy economy mode, the MS shall remain synchronized to the 
BS transmission. 

Also, when the BS allocates an assigned channel, it may indicate that, when appropriate, MS "napping" is permitted on 
that assigned channel according to the specified napping reception pattern and napping reception frames. When the MS 
is in napping mode, it receives at least the downlink slot(s) indicated by the napping reception pattern in the napping 
reception frames. 



1 9.4.6 Support of concurrent calls 



Depending on the class of the mobile, concurrent calls may be supported by LLC (see clause 22) and MAC (see 
clause 23) protocols. 

1 9.4.7 Support of air-interface encryption 

The support of encryption is optional and shall be indicated as part of the MS capabilities (i.e. in the class of MS). 

If this mode is supported, the MAC shall encrypt signalling messages as instructed by the upper layers on a message 
basis. Encrypted messages shall be indicated in the MAC header in order to enable the receiving end to de-encrypt the 
message content. 

The MAC may in addition encrypt the content of the half slots coming from the TMD-SAP. This may also apply to an 
established encrypted call. The encrypted speech shall then be encrypted once more in the MAC. In this case, 
encryption synchronization messages shall also be encrypted at the MAC level and decrypted before being passed 
through the TMD-SAP at the receiving side. 

1 9.5 Scenarios for primitives and PDU transfer on the air 
interface 

Figures 19.15, 19.16, 19.17 and 19.18 show example scenarios illustrating message exchanges for set-up of a circuit 
mode call. Figures 19.15 and 19.16 show the primitives and PDUs on a calling MS air interface. Figures 19.17 
and 19.18 show the primitives and PDUs on a called MS air interface. 

NOTE: Some features represented here may be optional. 

Refer to clauses 20 and 21 for definition of primitives and elements, and PDUs respectively. Refer to clauses 1 1 and 14 
for the call set-up definition. The involved MLE, LLC and MAC protocols are found in clauses 18, 22 and 23 
respectively. 
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Figure 19.15: Primitives and PDUs on thie calling MS air interface 
for an individual call with direct set-up signalling - Calling MS side 



£75/ 



521 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



Physical 
Layer 



MAC 



SwMI side 

LLC MLE 



CMCE 



(1) 



(2) 



(3)- 



(4) 



TMV- 

UNITDATA 

indication 

>- 

[SCH/HU] 



[MAC- 
ACCESS]- 



TMA- 

UNITDATA 

indication 



[BL-DATA] 







TMA- 






UNITDATA 


TMV- 




request 


UNITDATA 


[MAC- , ' 


\ 


request 


RESOURCE] 


TMA-REPORT 




[SCH/F] 




indication 
\ 



[BL-ACK] 



TMV- 


[MAC- , - ' ' 
. RESOURCE] 


TMA- 

UNITDATA 
^ request 


UNITDATA 
request 


\ 

TMA-REPORT 
indication 

\ 


[SCH/F) 



TL- 

DATA 

indication 



[MLE- 
UNITDATA] 



TL- 

DATA 

response 



[MLE- ' 
UNITDATA] 



TL-REPORT 
indication 



TL- 

DATA 

request 



[MLE- ' 
UNITDATA] 



[BL-DATA] 



TMV- 

UNITDATA 

indication 

[STCH] ^ 

or 
[SCH/HU] 



[MAC- 
DATA] 

or 
[MAC- 
ACCESS] 



TMA- 

UNITDATA 

indication 



TL-REPORT 
indication 



[BL-ACK] 



TL- 

DATA 

confirm 



MLE- 

UNITDATA 
indication ^ 



MLE- 

UNITDATA 
, request 



[U-SETUP] 



[D-CALL 
PROCEEDING] 



MLE-REPORT 
indication 



MLE- 

UNITDATA 
, request 



[D-CONNECT] 



MLE-REPORT 
indication 



Figure 19.16: Primitives and PDUs on the calling MS air interface 
for an individual call with direct set-up signalling - SwMI side 
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Figure 19.17: Primitives and PDUs on the called MS air interface 
for an individual call with direct set-up signalling - SwMI side 
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Figure 19.18: Primitives and PDUs on the called MS air interface 
for an individual call with direct set-up signalling - Called MS side 



£75/ 



524 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 



20 Layer 2 service description 

20.1 Introduction 

Clause 20 describes the services offered by layer 2 (see clauses 22 and 23) of the V+D TETRA air interface (see 
EN 300 392-1 [6], clause 6). The service description is done in terms of SAPs, primitives and their parameters. 
Throughout clause 20 the word "shall" is used with SAPs, service primitives and parameters for traceability reasons in 
the protocol model, but those SAPs and primitives are not testable. As this applies inside an MS at non-specified 
reference points (see EN 300 392-1 [6], clauses 4 and 5), the following description does not imply any specific 
implementation. 

20.2 Layer 2 service description 

20.2.1 LLC SAPs 

The model of the DLL comprises two sub-layers: the LLC and the MAC. The layer architecture is presented in 
clause 19. 

Layer 2 shall provide services to the MLE through three SAPs: TLA, TLB, TLC as shown in figure 20.1. These services 
are defined in terms of primitive actions and events of the service, parameters associated with each primitive action and 
event, interrelationship between primitives and the valid sequences of those actions following the ISO model 
ISO/IEC 8348 [i.7]. 

NOTE 1: The MLE layer is also called "service user" in the layer 2 descriptions. 

Signalling Broadcast Layer management 

MLE 



LLC 



r^ r^ r 

TLA-SAP TLB-SAP TLC-SAP 

Figure 20.1 : SAPs at the MLE-LLC boundary 



The SAPs in this model are: 

• TLA-SAP for signalling: 

this SAP shall be used for data transfer and for control of the data transfer; the services are described in 
tables 20.8 and 20.9; 

• TLB-SAP for broadcast: 

this SAP shall be used for broadcasting purposes; 

• TLC-SAP for layer management: 

this SAP shall be used for the local control related to the cell selection/reselection in the MLE. In this 
model it is also used for local layer management inside one protocol stack. For example, it may be used 
for passing values (e.g. valid addresses, MNC, MCC) between the service user and the protocol layer 2. 

NOTE 2: The peer-to-peer services provided by the TLA-SAP and the TLB-SAP correspond to services between 

one BS and one or several MSs. The services provided by the TLC-SAP correspond to the services within 
an MS. 

In addition to these services to the MLE, the LLC may provide an additional SAP: the TLE-SAP. This is the layer 2 
signalling SAP. The LLC offers layer 2 signalling services to the MAC through this SAP. 
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20.2.2 MAC SAPs 



The MAC shall provide three SAPs to the LLC: TMA-S AP, TMB-SAP and TMC-SAP. Their role is the same as the 
corresponding TLA-SAP, TLB-SAP and TLC-SAP. 

In addition to these, the MAC shall provide an additional SAP to the U-plane application: the TMD-SAP. The services 
offered at this SAP are illustrated in clause 19 and described in clause 23. 



20.2.3 Generic primitive types 



Four different types of primitives are used in this protocol model as defined in ISO/IEC 8348 [i.7] and further explained 
in ETS 300 125 [5]. TETRA specific explanations are shown below in the notes. 

The REQUEST primitive type shall be used when a higher layer is requesting a service from the lower layer. 

The INDICATION primitive type shall be used by a layer providing a service to notify the higher layer of any specific 
activity which is service related. The INDICATION primitive may be the result of an activity of the lower layer related 
to the primitive type REQUEST at the peer entity. 

NOTE 1: Primitives at the TxC-SAP are not normally directly related to any data transfer service. 

The RESPONSE primitive type shall be used by a layer to acknowledge receipt, from a lower layer, of the primitive 
type INDICATION. 

NOTE 2: In TETRA, a RESPONSE primitive may be used with upper layer data in order to force transportation of 
acknowledgement and service user data (TL-SDU) in the same transmission. The TL-SDU will then be 
placed in the PDU containing the acknowledgement. 

The CONFIRM primitive type shall be used by the layer providing the requested service to confirm that the activity has 
been completed. 

NOTE 3: The CONFIRM primitive may be the result of an activity of the lower layer related to the primitive type 
RESPONSE at the peer entity and in that case it may contain service user data (TL-SDU). 

20.2.3a Usage of primitives at tine TLE-SAP 

In TETRA, the TLE-SAP is an exceptional case where the LLC provides a service to a lower layer (i.e. the MAC). Two 
primitive types are used at this SAP. 

The REQUEST primitive type shall be used when the MAC is requesting a service from the LLC. 

The INDICATION primitive type shall be used by the LLC to notify the MAC of any specific activity which is service 
related. The INDICATION primitive may be the result of an activity of the LLC related to the primitive type 
REQUEST at the peer entity. 

Additionally the CONFIRM primitive type may be used by the LLC to confirm that a requested activity has been 
completed. 

20.2.4 Parameters definition for LLC and MAC service primitives 
20.2.4.1 Address type 

Address type shall be used by the service user to indicate to the MAC which address type will be used for transmission. 
It shall be used to distinguish between a user address (i.e. SSI), a management address (i.e. SMI) or an un-exchanged 
address (i.e. USSI). 
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20.2.4.2 Advanced link service 

Advanced link service shall define which advanced link service is used: 

• acknowledged; or 

• unacknowledged. 

20.2.4.3 Call release 

This parameter shall indicate call release to the MS-MAC e.g. when a user within a group call wishes to leave that 
group call. 

20.2.4.4 Channel number 

The channel number parameter shall identify the frequency of the RF channel that the MS shall use for the requested 
service or that layer 2 has used for the indicated service. 

20.2.4.5 Channel change accepted 

The channel change accepted parameter shall be used by the higher layers to indicate whether the MAC should accept 
or not the channel allocation indicated by the "channel change handle" parameter, see clause 20.2.4.6. 

20.2.4.6 Channel change handle 

This parameter shall be a local identifier which acts as a reference to a particular channel allocation when the MAC 
requires an instruction about whether to accept that channel allocation (i.e. when the MAC sets the "channel change 
response required" parameter to "true"). Its implementation is outside the scope of the present document. 

20.2.4.7 Channel change response required 

This parameter shall be used for the MAC to indicate to the higher layers that a channel allocation command was 
received with a particular SDU and that the MAC requires an instruction about whether to accept the channel allocation. 
In this case the parameter shall be set to "true"; otherwise it shall be set to "false". 

20.2.4.8 Channel class label 

This parameter shall be a local identifier which acts as a reference to a particular channel class when the higher layers 
(i.e. MLE) request assessment of the path loss for that channel class. Its implementation is outside the scope of the 
present document. 

NOTE: A channel class is defined as a set of values indicating the RF characteristics of a concentric channel. 

20.2.4.9 Channel information 

This parameter may be used for the MAC to provide information about a channel to the higher layers. For example, it 
may indicate the modulation mode and the bandwidth of the channel, and whether the channel is a conforming channel, 
non-conforming concentric channel or sectored channel. 

NOTE: A conforming channel is a special case of a concentric channel. All sectored channels are non-conforming 
channels. 
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20.2.4.1 Characteristics of channel class to be assessed 

This parameter shall be used for the higher layers (i.e. MLE) to provide information to the MAC about a channel class 
that is to be assessed. It includes the following information: 

• modulation mode for that channel class; 

• maximum MS transmit power for that channel class; 

• minimum RX access level for that channel class; and 

• BS transmit power relative to main carrier (see note 1). 

NOTE 1: For an assessment of a channel class on the serving cell, this refers to the BS transmit power for that 

channel class relative to the BS transmit power on the main carrier of the serving cell. For an assessment 
of a channel class on a neighbour cell, this refers to the BS transmit power for that channel class relative 
to the BS transmit power on the main carrier of that neighbour cell. 

NOTE 2: Assessment of a channel class on the serving cell is performed by using measurements on the current 

channel or on the main carrier of the serving cell, together with the characteristics of the channel class to 
be assessed, to predict the path loss on channel(s) corresponding to that channel class. Assessment of a 
channel class on a neighbour cell is performed by using measurements on the main carrier of that 
neighbour cell, together with the characteristics of the channel class to be assessed, to predict the path loss 
on channel(s) corresponding to that channel class. 

20.2.4.1 1 Characteristics of RF channel to be monitored 

This parameter shall be used for the higher layers (i.e. MLE) to provide information to the MAC about an RF channel 
that is to be monitored. It may comprise the following information: 

modulation mode for RF channel to be monitored; 

bandwidth of RF channel to be monitored; 

maximum MS transmit power on RF channel to be monitored; 

minimum RX access level for RF channel to be monitored; and 

information about the discontinuous mode on the RF channel to be monitored. 

It may also indicate whether the RF channel that is to be monitored is the main carrier of a neighbour cell, or a sectored 
carrier, or the main carrier of the serving cell. 

20.2.4.1 2 CSS endpoint identifier 

This parameter shall be an endpoint identifier which refers to a Carrier Specific Signalling (CSS) channel that has been 
allocated to the MS. Alternatively, it may refer to a common channel (MCCH or common SCCH) if the MS is allocated 
an assigned channel on the main carrier and is permitted to use the common channel. 

20.2.4.13 Data category 

This parameter may be used to indicate information about the type of data in the TM-SDU and the required reliability 
level for the transmission, enabling the MAC to make appropriate decisions about: 

• the modulation to use to send the TM-SDU on a D8PSK channel; or 

• the modulation level and coding rate to use to send the TM-SDU on a QAM channel. 
This parameter is also used to indicate information about the data in the LLC sending buffer. 
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For example, this parameter may indicate whether the data is: 

background class data - reliability level 1 ; or 

background class data - reliability level 2; or 

background class data - reliability level 3; or 

telemetry class data - reliability level 1 ; or 

telemetry class data - reliability level 2; or 

telemetry class data - reliability level 3; or 

real-time class data; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 1; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 2; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 3. 

NOTE 1: In this example of possible data categories, it is intended that reliability level 3 refers to better (i.e. higher) 
reliability than reliability level 2, and reliability level 2 refers to better (i.e. higher) reliability than 
reliability level 1 . 

NOTE 2: In this example of possible data categories, three reliability levels are used for background class data, 
telemetry class data and non-classified data. In an implementation, fewer than three reliability levels 
could be used if preferred. For instance, if preferred, two reliability levels could be used for background 
class data and/or telemetry class data and/or non-classified data. 

20.2.4.1 4 Data class activity information 

This parameter may be used for the higher layers to inform the MAC about the most demanding data class for currently 
active PDF contexts. It may indicate whether the most demanding data class is the background data class, the telemetry 
data class or the real-time data class (or no data class). 

NOTE 1 : The real-time data class is more demanding than the telemetry data class, and the telemetry data class is 
more demanding than the background data class. 

NOTE 2: If the MS is using concurrent channels, the higher layers may provide data class activity information 
independently for each endpoint identifier i.e. specifying the most demanding data class for currently 
active PDF contexts using each endpoint identifier. 

20.2.4.1 5 Data class information 

This parameter may be used to indicate information about the type of data in the TL-SDU, enabling the DLL to make 
appropriate decisions about the modulation (and coding rate for QAM) to use to send the TL-SDU and any segment 
retransmissions on a D8FSK or QAM channel. 

This parameter may indicate whether the data in the TL-SDU is: 

• background class data; or 

• telemetry class data; or 

• real-time class data; or 

• non-classified data (i.e. TL-SDU does not contain packet data). 

NOTE: In an implementation, the "non-classified data" may be subdivided into multiple classes. 
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20.2.4.16 Data priority 



The data priority parameter indicates the packet data priority. The data priority parameter may take one of eight defined 
values of data priority (0 to 7) or may contain the value "undefined". 

NOTE: The data priority requirements for the data in the LLC's sending buffer may be used by the MAC to send 
the MS's current short-term data priority requirements for reserved access to the BS. Data priority may 
also be used in the LLC to define the sending order of TL-SDUs (together with the PDU priority). 

20.2.4.1 7 Data priority random access delay factor 

This parameter may be used for the higher layers to provide the MAC layer with the value of the data priority random 
access delay factor (in the range to 7). The value of this parameter is sent by the SwMI to the MS at SNDCP level, but 
is used by the MAC in its data priority procedures. 

20.2.4.1 8 Distribution on the 1 8th frame 

In the case of minimum mode, this parameter shall define on which timeslot the MS shall listen to the downlink on the 
frame 18. It may be received by the MS at subscription or at registration. 

20.2.4.1 9 Dual watch energy economy group 

This shall be one of the allowed dual watch energy economy duty cycles. 

20.2.4.20 Dual watch startpoint 

The dual watch startpoint shall be the absolute frame and multiframe number to which the MS shall listen (if 
practicable) before entering the duty cycle defined by the dual watch energy economy group. 

20.2.4.21 Encryption, air interface 

This parameter shall define whether the signalling message shall be encrypted (using air interface encryption) by the 
MAC or not before its transmission over the air interface. At the receiving side, it shall define whether the message has 
been encrypted for transmission over the air interface. 

20.2.4.22 Endpoint identifier 

This local identifier shall be used to distinguish between multiple concurrent MAC resources (i.e. MAC channels). It 
refers to which MAC resource may be used for that service. Its implementation is outside the scope of the present 
document. 

NOTE: Refer to the handle to the request described in clause 20.2.4.3 1 . 

20.2.4.23 Energy economy group 

This shall be one of the eight allowed energy economy duty cycles as defined in clause 23. 

20.2.4.24 Energy economy startpoint 

This shall be the absolute frame and multiframe number to which the MS shall listen before entering the duty cycle 
defined by the energy economy group. 

20.2.4.25 PCS flag 

The PCS flag shall be used to indicate to the LLC whether extended error protection shall be applied (for basic link and 
extended advanced link). 
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20.2.4.26 Half slot condition 

This shall indicate whether a half traffic slot was received successfully. 

20.2.4.27 Half slot content 

This shall define the U-plane information content that is to be carried (or was received) in a half slot in a circuit mode 
transmission. 

20.2.4.28 Half slot importance 

This shall define the importance of the U-plane information that is to be carried in the circuit. It may be defined 
according to table 20. 1 . 

Table 20.1 : Definition of half slot importance 



Half slot importance 


Meaning 





No importance (could be used for discontinuous TX) 


1 


Low 


2 


IVIedium 


3 


High 



20.2.4.29 Half slot position 

This shall define the position of the U-plane information within the timeslot (i.e. first or second half slot). 

20.2.4.30 Half slot synchronization 

This shall be a local signal provided by the MS MAC to the U-plane application so that the first half slot and second 
half slot parameters correspond to the first and, respectively, second half slot of the timeslot. It is provided for the 
purpose of this description and does not imply any particular implementation. It requires that the application keeps 
synchronized to the half slot in the MAC transmission. 

20.2.4.31 Handle to the request 

This shall be a local identifier which acts as a reference to a specific service request (parent) and its children. Its 
implementation is outside the scope of the present document. It is considered that the handle to the request is unique 
over all link identifiers and endpoint identifiers and is independent of the link identifier and endpoint identifier. The 
handle to the request is also used on received data to link a potential acknowledgement to it. 



20.2.4.32 Layer 2 data priority lifetime 



This parameter may be used for the higher layers to provide the MAC layer with the value of the layer 2 data priority 
lifetime. The value of this timer is sent by the SwMI to the MS at SNDCP level, but is used by the MAC in its data 
priority procedures. 

20.2.4.33 Layer 2 data priority signalling delay 

This parameter may be used for the higher layers to provide the MAC layer with the value of the layer 2 data priority 
signalling delay. The value of this timer is sent by the SwMI to the MS at SNDCP level, but is used by the MAC in its 
data priority procedures. 

20.2.4.34 Layer 2 signalling message 

The layer 2 signalling message is the service user data message from the MAC layer to the LLC layer. It shall be the 
layer 2 signalling information in a layer 2 signalling PDU, including the layer 2 signalling subtype. It is considered here 
as a parameter of the service primitive. 
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20.2.4.35 Layer 2 signalling message length 

The layer 2 signalling message length shall be the number of bits of the layer 2 signalling message. 

20.2.4.36 Link identifier 

This local identifier shall be used to distinguish between multiple concurrent service instances in the LLC. It indicates 
on which link the message shall be sent from the different basic and advanced links. Its implementation is outside the 
scope of the present document. 

NOTE: Refer to the handle to the request described in clause 20.2.4.3 1 . 

20.2.4.37 Link performance information 

This parameter may be used for the LLC to provide information to the MAC about current advanced link performance, 
in order to aid the MAC to make appropriate decisions about the modulation (and coding rate for QAM) to use to send 
TM-SDUs on a D8PSK or QAM channel for some data categories. For example, the LLC may provide information 
derived from the acknowledgement bit maps in received AL-ACK, AL-RNR, AL-X-ACK and AL-X-RNR PDUs. The 
method for derivation of this information is outside the scope of the present document. 

20.2.4.38 LLC timer status 

This parameter is used for the LLC to indicate to the MAC whether any of its timers that are measured in downlink 
signalling frames are currently running. The LLC timers that are measured in downlink signalling frames are 
timers T.251, T.252, T.261, T.263 and T.265; see annex A. 

NOTE: The LLC timer status information may be used by the MAC in its napping procedures. 

20.2.4.39 Lower layer resource availability 

The lower layer resource availability shall indicate when MAC layer has lost physical resources identified by the 
endpoint identifier. It may be used when the physical resource is regained. 

20.2.4.40 MAC broadcast information 

This parameter shall indicate information in the MAC header of the S YSINFO or S YSINFO-Q PDU that is relevant to 
the higher layers. 

EXAMPLE: For example, information in the S YSINFO (and S YSINFO-Q) PDU about support of data priority 
by the BS is used by the MAC in the MS but is also used by the SNDCP. 

20.2.4.41 Main address 

The main address shall refer to the ASSI, ISSI, GSSI, SMI or USSI value as defined in EN 300 392-1 [6], clause 7. It 
shall consist of the MS source address for the uplink except for the low level group presence indication, for which the 
GSSI shall be used (refer to clause 23.5.2.3.2). It shall consist of the destination address for the downlink. 

20.2.4.42 Maximum schedule interval 

This parameter shall be used in the case of scheduled data to indicate the maximum valid schedule interval for this 
schedule. (This is the sum of the schedule repetition period and the schedule timing error negotiated for this schedule.) 

20.2.4.43 MLE activity indicator 

This parameter indicates whether any of the layer 3 entities or advanced links are currently active. Where the MS-MAC 
is capable of performing energy economy or dual watch procedure, MLE activity indicator shall be used by the 
MS-MAC in the management of these procedures. 
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20.2.4.44 MS default data priority 

This parameter may indicate the MS default data priority that the higher layers have negotiated with the SwMI; in this 
case, the MS default data priority parameter takes one of eight defined values of data priority (0 to 7). Otherwise this 
parameter may contain the value "not applicable" to indicate that: 

• the MS does not currently have an MS default data priority; or 

• the SNDCP is not in the READY state; or 

• the current BS does not support data priority. 

20.2.4.45 New endpoint identifier 

This parameter shall be an endpoint identifier which refers to an additional resource allocation that has been given to the 
MS. 

20.2.4.46 Number of tt/4-DQPSK timeslots 

The number of 7i/4-DQPSK timeslots shall be used to define the throughput of a circuit mode service (with the selected 
error protection). It may be used to define the maximum throughput of a packet mode service. 

20.2.4.47 Number of repetitions of layer 2 signalling message 

The number of repetitions of layer 2 signalling message may be used for the MAC to define the required number of 
repetitions. If it is not included, the LLC uses a predefined number. 

20.2.4.48 Number of repetitions of TL-SDU 

The number of repetitions of TL-SDU may be used for the higher layers to define the required number of repetitions of 
a TL-SDU on the unacknowledged basic link. If it is not included, the LLC uses a predefined number. 

20.2.4.49 Operating mode 

The operating mode shall be used for the higher layers (i.e. CMCE) to give instructions to the MS MAC to switch 
between signalling and traffic mode. It may comprise the following indications: 

switch U-plane on/off; 

TX-grant flag; 

simplex/duplex flag; 

type of circuit (i.e. TCH/S, TCH/7,2, TCH/4,8, TCH/2,4); 

interleaving depth N; 

end-to-end encryption flag; 

user device; 

endpoint identifier. 

20.2.4.50 Packet data flag 

This parameter shall indicate whether the TL-SDU contains packet data from the SNDCP or other signalling 
information. For example, it may be used by the LLC when it is deciding on the sending order of TL-SDUs. 
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20.2.4.51 Path loss 

Related to the cell selection/reselection mechanism and the channel/sector advice and assigned channel replacement 
procedures, and based on measurements, the path loss consists of five variables {CI, C2, C3, C4 and C5) that may be 
calculated. Their definition and the formulas are in clause 23 together with the different procedures. 

20.2.4.52 PDU priority 

This priority field shall be used within the LLC and MAC local to one MS. It shall not be transported to the peer entity. 
It may be used in the LLC to define the sending order of TL-SDUs. It shall be used in the MAC as the priority in the 
random access protocol. The number of supported priority levels for random access control purposes shall be eight. 
PDU priority ordering in a queuing process is an optional feature. The random access procedure and PDU priorities are 
defined in clause 23. 

20.2.4.53 Periodic reporting timer 

The periodic reporting timer shall indicate the longest time between any transmissions from the MS to the BS, refer to 
clause 16.10.7b for definition of the values. 

20.2.4.54 Quality indication 

This quality indication may be used to indicate locally what the reception quality is. 

20.2.4.55 Quality of Service (QoS) 

The QoS parameters shall be used to facilitate the negotiation of the quality of service as defined in EN 300 392-1 [6]. 
The quality of service in this model is defined at the DLL as a set of TETRA specific parameters. 

NOTE 1 : Most of the parameters and selection of their values are either MS or network dependent. 

NOTE 2: TETRA specific parameters may or may not control all aspects of each QoS parameter at the network 
layer SAP. 

Parameter values for the throughput for constant delay services shall be as defined in table 20.2. 

Table 20.2: Throughput for constant delay services 



Parameter 


Values 


Remarks 


Transmission rate 


2 400, 4 800 or 7 200 bit/s times tlie 
Number of tt/4-DQPSK timeslots 


TIVID-SAP (negotiable) 



Parameter values for the throughput for variable delay services shall be as defined in table 20.3. 

Table 20.3: Throughput for variable delay services 



Parameter 


Values 


Remarks 


IVIaximum transmission rate 
(optional at the DLL - see note) 


Number of tt/4-DQPSK timeslots 1 to 4 


AL-SETUP PDU (negotiable) 


IVIean transmission rate 
(optional at the DLL - see note) 


See clause 21 for definition 


AL-SETUP PDU (negotiable) 


Maximum length of TL-SDU 


N.251 for basic link 


Predefined 


N.271 for advanced link 


AL-SETUP PDU (negotiable) 


Advanced link type 


Original, extended 


AL-SETUP PDU (negotiable) 


TL-SDU window size 


N.272 


AL-SETUP PDU (negotiable) 


NOTE: The maximum transmission rate and mean transmission rate may be negotiated in the AL-SETUP PDU, 
in terms of tt/4-DQPSK timeslots. Alternatively (for example, if QoS information has been negotiated by 
the SNDCP during PDP context activation), the AL-SETUP PDU may provide no information related to 
radio resources. 
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The parameters for the residual error rate and residual error probability shall be as defined in table 20.4. 

Table 20.4: Residual error rate 



Parameter 


Values 


Remarks 


The use of FCS 


Included, not included 


Local selection in the basic link 
services and the extended advanced 
link services 



Parameters for the transfer failure probability shall be as defined in table 20.5. 

Table 20.5: Transfer failure probability 



Parameter 


Values 


Remarks 


IVIaximum number of TL-SDU 
retransmissions 


N.252 and N.253 for basic link 


Predefined or, for N.253, optionally 
indicated by the service user for each 
TL-SDU 


N.273 and N.282 for advanced link 


AL-SETUP PDU (negotiable) 


N.293 for layer 2 signalling 


Predefined or indicated by the IVIAC 
for each layer 2 signalling message 


IVIaximum number of segment 
retransmissions 


N.274 


AL-SETUP PDU (negotiable) 



Parameters for the NC Release failure probability shall be as defined in table 20.6. 

Table 20.6: NC Release failure probability 



Parameter 


Values 


Remarks 


Number of disconnection repeats 


N.263 


Predefined 



20.2.4.56 Reconnection result 

Reconnection result shall be used to indicate the result of the advanced link reconnection. The values shall be: 

• success; 

• random access failure; 

• reconnection failure; 

• reject. 
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20.2.4.57 Report 

Report shall generally indicate the progress or failure of information transfer and the cause of it. 

The protocol model uses the report parameters in the protocol description at the A-SAP, C-SAP, D-SAP and E-SAP. 
The A-SAP, C-SAP and E-SAP reports (TLA-SAP, TLC-SAP, TLE-SAP, TMA-SAP and TMC-SAP) are defined in 
table 20.7. 

Table 20.7: Reports at TMA-, TMC-, TLA-, TLC- and TLE-SAPs 



Report 


SAP 


Aborted, SDL) not completely sent 


IMA, TLA, TLE 


Aborted, SDU sent at least once 


TMA, TLA, TLE 


Channel replacement is advisable 


TMC, TLC 


Channel replacement may be beneficial 


TMC, TLC 


Close 


TLA 


Common channel deallocated 


TMC, TLC 


Complete transmission by stealing or by reserved access 


TMA 


Current channel performance is acceptable 


TMC, TLC 


Disconnection failure 


TLA 


Downlink failure 


TMC, TLC 


Failed transfer (e.g. maximum number of re-transmissions exceeded) 


TLA, TLE 


First complete transmission 


TLA, TLE 


First complete transmission by random access 


TMA 


Fragmentation failure 


TMA 


Incoming disconnection 


TLA 


Layer two transmission activities continuing 


TLA 


Local disconnection 


TLA 


Maximum path delay exceeded 


TMC, TLC 


Random access failure 


TMA, TLA, TLE 


Reject 


TLA 


Reset 


TLA 


Schedule timing prompt 


TMC, TLC 


Service change 


TLA 


Service definition 


TLA 


Service not supported 


TLA 


Service temporarily unavailable 


TLA 


Set-up failure 


TLA 


Successful complete transmission by random access 


TMA, TLE 


Success, successful transfer 


TLA, TLE 


Usage marker mismatch 


TMC, TLC 


Uplink failure 


TMC, TLC 



NOTE: The report parameter may be used to indicate a cause or a reason and possibly position of an error. 

20.2.4.58 Scanning measurement method 

This parameter shall specify which of the several methods of measurement the MAC shall use for the scanning process. 

20.2.4.59 SCCH information 

This parameter shall be used in the MAC to calculate which common control channel to use when common SCCHs are 
in operation. It may be received by the MS at subscription or at registration. 
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20.2.4.60 Scheduled data status 

This parameter shall be used to indicate whether the TL-SDU should be treated as: 

• not scheduled data; or 

• initial scheduled data; or 

• scheduled data. 

NOTE: Within layer 2, a TL-SDU labelled as "initial scheduled data" is treated in the same way as "scheduled 
data" for the purposes of LLC ordering of TL-SDUs, but is treated in the same way as "not scheduled 
data" for the purposes of deciding when the MAC may use random access. 

20.2.4.61 Schedule repetition information 

This parameter shall be used for the higher layers (i.e. SNDCP) to instruct the MS MAC to start giving timing prompts 
at the specified intervals for the schedule corresponding to the specified NSAPI. It may also be used for the higher 
layers to instruct the MS MAC to stop giving timing prompts for the schedule corresponding to the specified NSAPI. It 
comprises the following subparameters: 

• NSAPI; 

• start-stop flag (start or stop); 

• schedule repetition period (as a number of slot durations). 

20.2.4.62 Scrambling code 

This shall contain the Mobile Network Identity (MNI) as described in EN 300 392-1 [6], clause 7. It shall be given to 
the scrambling process in the lower MAC together with the colour code. 

20.2.4.63 Set-up report 

This shall be used to report set-up phase with the higher layer: 

• success; 

• service change (proposed parameters); 

• parameters acceptable; and 

• parameters not acceptable. 

20.2.4.64 Stealing permission 

This parameter shall define whether the MAC may use stealing to send this SDU. Within layer 2 it may have the 
following meanings: 

• steal immediately; 

• steal within time T. 2 14; 

• steal when convenient; or 

• stealing not required. 

The value "steal within time T.214" should be used for the reply to a BS message received while the MS is transmitting 
traffic. 
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20.2.4.65 Stealing repeats flag 



This shall be used by the higher layers in the MS to trigger a special stealing method in the MAC (see clause 23). This 
method should only be used for signalling at the end of an uplink traffic transmission (e.g. for U-TX-CEASED or 
possibly U-DISCONNECT). 

20.2.4.66 Stolen indication 

This shall indicate whether or not the information content of a half slot is stolen for signalling purposes. At the 
transmitting side, this parameter may be used to force signalling mode in the MAC for either the first or both half slots 
within a timeslot to be transmitted. At the receiving side, this parameter shall be available to the U-plane application to 
enable correct handling of stolen information. 

20.2.4.67 Subscriber class 

A subscriber class shall define a population subdivision e.g. for random access control. The operator may define the 
values and meaning of each class. The subscriber class information is received by the MS at subscription or at 
registration. If the MS receives subscriber class information at subscription, and then also is assigned subscriber class 
information at registration, then the information at registration shall be used. 

The subscriber class parameter as supplied in primitives from layer 3 is a bit mapped field which indicates for each 
class whether the MS belongs to that class. 

20.2.4.68 Threshold level 

Based on measurements as defined in clause 23, this shall be the calculated value of some global variable used in the 
MLE in the process of cell selection/reselection. 

20.2.4.69 Threshold values 

The values shall be thresholds imposed in the MAC by the MLE to take a relevant action (e.g. inform MLE using 
suitable primitive) if some measured and/or calculated MAC parameters exceed these limits. 

20.2.4.70 TL-SDU 

The TL-SDU is the service user data message from the MLE layer. It shall be the MLE PDU including the MLE header. 
It is considered here as a parameter of the service primitive. 

20.2.4.71 TL-SDU length 

The TL-SDU length shall be the number of bits of the TL-SDU. 

20.2.4.72 TM-SDU 

The TM-SDU is the service user data message from the LLC. It shall be the LLC PDU including the LLC header and 
optional ECS. It is considered here as a parameter of the service primitive. 

20.2.4.73 TM-SDU length 

The TM-SDU length shall be the number of bits of the TM-SDU. 

20.2.4.74 User device 

This parameter may indicate to which U-plane device the primitive is intended. The usage of user devices is outside the 
scope of the present document. 

20.2.4.75 Valid addresses 

Valid addresses are the addresses that the MS MAC shall recognize as the ones attached to the MS. 



£75/ 



538 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



20.3 Services provided by LLC 
20.3. 1 Services at the TLA-SAP 

The SAP may provide one or more logical channels marked by link identifiers. The service user shall select the wanted 
service by using a service request primitive with a link identifier as a parameter. The direction of the information flow 
can be from BS to MS, from MS to BS or both; it can also be local control information inside the MS or BS. 

The TLA-SAP shall be used for addressed signalling and data transfer. Table 20.8 shows the relationship for one LLC 
instance. There shall be an individual instance of LLC for each valid address. 

Table 20.8: Services provided at the TLA-SAP 



Service description for TLA-SAP 


Address 


Direction of tlie 
information flow 


Point-to-point acl<nowledged 


individual SSI 


Bi-directional 


Point-to-point unacl<nowledged 


individual SSI 


Bi-directional 


Point-to-multipoint unacl<nowledged 


group SSI (GSSi) 


Downlink 


Point-to-multipoint with presence indication 


group SSI (GSSI) 


Bi-directional 



NOTE: In the present document only the BS may initiate the presence indication service. 

Under the TLA-SAP, the LLC shall use the TMA-SAP for transferring the information down to the MAC. 

The LLC may offer basic link (connectionless mode) service and advanced link (connection orientated mode) service. 
Within each of these services both an acknowledged and an unacknowledged data transfer is defined in the protocol. 
These possibilities and normal usage are shown in table 20.9. 

Table 20.9: Data transfer relationships available in the LLC 



Service offered 


Aclcnowledged data transfer 


Unacknowledged data transfer 


Basic link 


Point-to-point signalling message or data 
transfer (short messages uplink and 
downlink) 


Point-to-point signalling or data transfer (short 
messages uplink and downlink); and 
broadcast or point-to-multipoint signalling message 
or data transfer (short messages downlink) 


Advanced link 


Point-to-point signalling or data transfer 
(long messages uplink and downlink) 


Point-to-multipoint signalling or data transfer 
(long messages downlink) 



Downlink transmissions addressed to an individual MS, in most cases, use the acknowledged service. Uplink 
transmissions with a valid address, in most cases, use acknowledged transfer. However, the unacknowledged basic link 
may be used for some types of point-to-point signalling or data transfer on the request of the service user. 

EXAMPLE: For example, the SNDCP uses the unacknowledged basic link service for sending point-to-point 
real-time class data on both uplink and downlink. 

Normal information transfer addressed to a group of MSs shall use unacknowledged transfer on the downlink. In the 
case of presence indication request the BS shall use a kind of acknowledged data transfer, with reserved access for the 
acknowledgement, knowing that if there are multiple responses from the MSs in the group, there is a risk of collision 
that will make the responses un-decodeable. If the message can be decoded, the BS will know that there was at least one 
responding MS. If there are collisions, the BS may assume presence of MSs from the measured RSSI on the uplink. 
How this measurement is done is outside the scope of the present document. 

The advanced link acknowledged mode may be used in all cases where an acknowledged service is required for a 
point-to-point data transfer. The advanced link may also be used for point-to-multipoint data transfer in 
unacknowledged mode. In this case data transfer normally consists of set-up phase, data transfer phase possibly with 
repetition and selective re-assembly of received data and disconnection phase. 
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20.3.2 Services at the TLB-SAP 

The TLB-SAP shall be used for un-addressed data transfer as presented in table 20.10. This includes the system 
information broadcast messages. In the protocol model there are no LLC functions under the TLB-SAP and the LLC 
shall convey information directly to the MAC using the TMB-SAP. 

Table 20.10: Services provided at the TLB-SAP 



Service description for TLB-SAP 


Address 


Direction 


Point-to-multipoint unacknowledged 


none 


Downlink 



20.3.3 Services at the TLC-SAP 

The TLC-SAP shall be used in this model for all local layer management control, such as scanning control and signal 
quality measurements (see table 20. 11). TLC-SAP does not provide any data transfer service over the air interface. 

Table 20.1 1 : Services provided at the TLC-SAP 



Service description for TLC-SAP 


Address 


Direction 


Local management and control 


None 


Bi-directional within the IVIS protocol stack 



20.3.3a Services at the TLE-SAP 

The TLE-SAP shall be used for layer 2 signalling, for which the LLC may offer an unacknowledged data transfer 
service to the MAC (see table 20.12). 

Table 20.12: Services provided at the TLE-SAP 



Service description for TLE-SAP 


Address 


Direction of tfie 
information flow 


Point-to-point unacknowledged 


individual SSI 


Bi-directional 


Point-to-multipoint unacknowledged 


group SSI (GSSI) 


Downlink 



20.3.4 LLC service primitives 

Tables 20.13 to 20.16 summarize LLC service primitives. If the service primitive is provided or not provided in both the 
basic and advanced links, then yes and no are used respectively. In other cases the LLC link type is mentioned. 

Table 20.13: TLA-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TL-CANCEL 


yes 


no 


no 


no 


TL-CONNECT 


advanced link 


advanced link 


advanced link 


advanced link 


TL-DATA 


yes 


yes 


basic link 


yes 


TL-DISCONNECT 


advanced link 


advanced link 


no 


advanced link 


TL-RECEIVE 


no 


advanced link 


no 


no 


TL-RELEASE 


advanced link 


yes 


no 


no 


TL-RECONNECT 


advanced link 


no 


no 


advanced link 


TL-REPORT 


no 


yes 


no 


no 


TL-UNITDATA 


yes 


yes 


no 


optional 



NOTE: TL-RECEIVE primitive is valid for the BS only. 
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Table 20.14: TLB-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TL-SYNC 


yes, BS 


yes, MS 


no 


no 


TL-SYSINFO 


yes, BS 


yes, MS 


no 


no 


TL-SYSINFO-Q 


yes, BS 


yes, MS 


no 


no 


Table 20.15: TLC-SAP service primitives 


Service primitive 


Request 


Indication 


Response 


Confirm 


TL-ASSESSMENT 


no 


yes 


no 


no 


TL-ASSESSMENT-LIST 


yes 


no 


no 


no 


TL-CONFIGURE 


yes 


yes 


no 


yes 


TL-MEASUREMENT 


no 


yes 


no 


no 


TL-MONITOR 


no 


yes 


no 


no 


TL-MONITOR-LIST 


yes 


no 


no 


no 


TL-REPORT 


no 


yes 


no 


no 


TL-SCAN 


yes 


no 


no 


yes 


TL-SCAN-REPORT 


no 


yes 


no 


no 


TL-SELECT 


yes 


yes 


yes 


yes 


Table 20.16: TLE-SAP service primitives 


Service primitive 


Request 


Indication 


Response 


Confirm 


TLE-CANCEL 


yes 


no 


no 


no 


TLE-REPORT 


no 


yes 


no 


no 


TLE-UNITDATA 


yes 


yes 


no 


optional 



20.3.5 Service primitive descriptions 

In tables 20.17 to 20.43 inclusive, which define parameters for the primitives, the following keys are used: 
M: Mandatory; 
C: Conditional; 

-: Not used. 

NOTE: The exact conditions of the presence for some conditional parameters are implied by the corresponding 
information flows and are not detailed in the service descriptions. 

20.3.5.1 Primitives at the TLA-SAP (MLE-LLC) 



20.3.5.1.1 



TL-CANCEL primitive 



TL-CANCEL request: this primitive may be used locally for an MS or BS to cancel a previous request. This primitive 
shall not send messages over the air interface. The parameters shall be as defined in table 20.17. 

Table 20.17: Parameters used in the TL-CANCEL primitive 



Parameter 


Request 


Handle to the request (see note) 


M 


NOTE: Not sent over the air interface. 
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20.3.5.1.2 



TL-CONNECT primitive 



The connection primitives, if required prior to a transfer, shall be used to establish a LLC advanced link. The 
parameters shall be as defined in table 20.18. 

TL-CONNECT request: this primitive shall be used by the layer 2 service user to initiate the establishment of an 
advanced link with a certain quality of service. It may also reset the established link. 

TL-CONNECT indication: this primitive shall be used by the layer 2 to inform the layer 2 service users that the 
establishment of an advanced link with a certain quality of service or the reset of the current advanced link has been 
requested. 

TL-CONNECT response: this primitive shall be used by the layer 2 service users to accept the establishment or the 
reset of the advanced link with a certain quality of service. According to the available resources, the value of the service 
parameters may also be modified (lower grade of service) in the response. In such a case, the advanced link 
characteristics will match these new features. 

TL-CONNECT confirm: this primitive shall be used by the layer 2 to inform the layer 2 service users that the 
establishment or re-establishment (reset) of the advanced link has been completed with a certain quality of service as 
indicated in the request primitive. 

Table 20.18: Parameters used in the TL-CONNECT primitive 



Parameter 


Request 


Indication 


Response 


Confirm 


Address type 


M 


M 


M 


M 


Main address 


M 


M 


M 


M 


Scrambling code (see note) 


M 


M 


M 


M 


Link identifier (see note) 


M 


M 


M 


M 


Endpoint identifier (see note) 


M 


M 


M 


M 


New endpoint identifier (see note) 


- 


C 


- 


C 


CSS endpoint identifier (see note) 


- 


C 


- 


C 


PDU priority (see note) 


M 


- 


M 


- 


Stealing permission (see note) 


M 


- 


M 


- 


Subscriber class (see note) 


M 


- 


M 


- 


Quality of Service 


M 


M 


M 


M 


Advanced link service 


M 


M 


M 


M 


Encryption, air interface 


M 


M 


M 


M 


Channel change response required (see note) 


- 


M 


- 


M 


Channel change handle (see note) 


- 


C 


- 


C 


Channel information 


- 


C 


- 


C 


Handle to the request (see note) 


M 


M 


M 


M 


Set-up report 


M 


M 


M 


M 


NOTE: Not sent over the air interface. 



NOTE: The usage of the advanced link service type indication in confirm primitive applies only to the BS side of 
the protocol. 

20.3.5.1 .3 TL-DATA primitive for the advanced link 

Parameters in acknowledged advanced link service for the following primitives shall be as defined in table 20.19. 

TL-DATA request: this primitive shall be used by the layer 2 service user to request transmission of a TL-SDU. 

TL-DATA indication: this primitive shall be used by the layer 2 to deliver the received TL-SDU to the layer 2 service 
user. 

TL-DATA confirm: this primitive shall be used by the layer 2 to inform the layer 2 service user that it has completed 
successfully the transmission of the requested TL-SDU. 
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Table 20.19: Parameters used in the TL-DATA primitive for advanced linl< 



Parameter 


Request 


Indication 


Confirm 


Address type 


M 


M 


M 


Main address 


M 


M 


M 


Link Identifier (see note 1 ) 


M 


M 


M 


Endpoint identifier (see note 1) 


M 


M 


M 


New endpoint identifier (see note 1) 


- 


C 


C 


CSS endpoint identifier (see note 1) 


- 


C 


C 


TL-SDU 


M 


C 


- 


TL-SDU length (see note 1) 


M 


c 


- 


Scrambling code 


M 


M 


M 


PDU priority (see note 1) 


M 


- 


- 


Stealing permission (see note 1) 


M 


- 


- 


Subscriber class (see note 1) 


M 


- 


- 


PCS flag 


C 


c 


C 


Encryption, air interface 


M 


M 


M 


Data priority (see note 2) 


M 


- 


- 


Packet data flag (see note 1 ) 


M 


- 


- 


Scheduled data status (see note 1) 


M 


- 


- 


IVIaximum schedule interval (see note 1) 


C 


- 


- 


Data class information (see note 1) 


C 


- 


- 


Channel change response required (see note 1) 


- 


M 


M 


Channel change handle (see note 1) 


- 


C 


C 


Channel information 


- 


C 


C 


Handle to the request (see note 1 ) 


M 


- 


M 


Report 


- 


- 


M 


NOTE 1 : Not sent over the air interface. 

NOTE 2: May be signalled over the air interface, collated with other data priority information. 



20.3.5.1.4 



TL-DATA primitive for the basic link 



In the acknowledged basic link data transfer service the parameters for the following primitives shall be as defined in 
table 20.20. 

TL-DATA request: this primitive shall be used by the layer 2 service user to request transmission of a TL-SDU. The 
TL-SDU will be acknowledged by the peer entity. 

TL-DATA indication: this primitive shall be used by the layer 2 to deliver the received TL-SDU to the layer 2 service 
user. 

TL-DATA response: this primitive shall be used by the layer 2 service user to respond to the previous TL-DATA 
indication primitive. The TL-DATA response primitive may contain a TL-SDU. That TL-SDU will be sent without an 
explicit acknowledgement from the peer entity. 

TL-DATA confirm: this primitive shall be used by the layer 2 to inform the layer 2 service user that it has completed 
successfully the transmission of the requested TL-SDU. Depending on the availability of the response primitive at the 
peer entity before transmission of the acknowledgement, the confirm primitive may or may not carry a TL-SDU. 
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Table 20.20: Parameters used in the TL-DATA primitive for basic linl< 



Parameter 


Request 


Indication 


Response 


Confirm 


Address type 


M 


M 


M 


M 


Main address 


M 


M 


M 


M 


Link identifier (see note) 


M 


M 


M 


M 


Endpoint identifier (see note) 


M 


M 


M 


M 


New endpoint identifier (see note) 


- 


C 


- 


C 


CSS endpoint identifier (see note) 


- 


C 


- 


C 


TL-SDU 


M 


C 


M 


C 


TL-SDU length (see note) 


M 


C 


M 


C 


Scrambling code 


M 


M 


M 


M 


PDU priority (see note) 


M 


- 


M 


- 


Stealing permission (see note) 


M 


- 


M 


- 


Subscriber class (see note) 


M 


- 


M 


- 


PCS flag 


M 


M 


M 


M 


Encryption, air interface 


M 


M 


M 


M 


Stealing repeats flag (see note) 


C 


- 


C 


- 


Data class information (see note) 


C 


- 


C 


- 


Channel change response required (see note) 


- 


M 


- 


M 


Channel change handle (see note) 


- 


C 


- 


C 


Channel information 


- 


C 


- 


C 


Handle to the request (see note) 


M 


M 


M 


M 


Report 


- 


- 


- 


M 


NOTE: Not sent over the air interface. 



20.3.5.1.5 



TL-DISCONNECT primitive 



The disconnection primitives shall be used to disconnect a LLC advanced link. The parameters shall be as defined in 
table 20.21. 

Table 20.21 : Parameters used in the TL-DISCONNECT primitive 



Parameter 


Request 


Indication 


Confirm 


Address type 


M 


M 


M 


Main address 


M 


M 


M 


Link identifier (see note) 


M 


M 


M 


Endpoint identifier (see note) 


M 


M 


M 


New endpoint identifier (see note) 


- 


C 


C 


CSS endpoint identifier (see note) 


- 


C 


C 


Scrambling code 


M 


M 


M 


PDU priority (see note) 


M 


- 


- 


Stealing permission (see note) 


M 


- 


- 


Subscriber class (see note) 


M 


- 


- 


Advanced link service 


M 


M 


M 


Encryption, air interface 


M 


M 


M 


Channel change response required (see note) 


- 


M 


M 


Channel change handle (see note) 


- 


C 


C 


Channel information 


- 


C 


C 


Handle to the request (see note) 


M 


- 


M 


Report 


M 


M 


M 


NOTE: Not sent over the air interface. 



NOTE 1: The only valid value for the report field in TL-DISCONNECT request primitive is "Close". 

NOTE 2: The usage of the advanced link service type indication in confirm primitive applies only to the BS side of 
the protocol. 
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20.3.5.1.5a 



TL-RECEIVE primitive 



TL-RECEIVE indication: this primitive shall be used by the layer 2 to report to the layer 2 service user that the 
reception of a TL-SDU has started or is ongoing on the layer 2. This primitive is valid for the BS only. 

Parameters for this primitive shall be as defined in table 20.22. 

Table 20.22: Parameters used in the TL-RECEIVE primitive (TLA-SAP) 



Parameter 


Indication 


Address type 


M 


Main address 


M 


Endpoint identifier (see note) 


M 


NOTE: Not sent over the air interface. 



20.3.5.1.6 



TL-RECONNECT primitive 



The reconnection primitives shall be used to reconnect an advanced link after a cell reselection. The parameters shall be 
as defined in table 20.23. 

TL-RECONNECT request: this primitive shall be used by the layer 2 service user in the MS after a cell reselection to 
initiate the reconnection of an advanced link which was being used in the previous cell. If successful, all parameters 
agreed for the advanced link in the previous cell shall apply in the new cell. 

TL-RECONNECT confirm: this primitive shall be used by the LLC to inform the layer 2 service user that the attempt 
to reconnect the advanced link has been successfully completed. A successful reconnection shall result in no change to 
the parameters which were agreed during the establishment of the advanced link in question. 

Table 20.23: Parameters used in the TL-RECONNECT primitive 



Parameter 


Request 


Confirm 


Address type 


M 


M 


IVlain address 


M 


M 


Linl< identifier (see note) 


M 


M 


Endpoint identifier (see note) 


M 


M 


New endpoint identifier (see note) 


- 


C 


CSS endpoint identifier (see note) 


- 


C 


Scrambling code 


M 


M 


PDU priority (see note) 


M 


- 


Stealing permission (see note) 


M 


- 


Subscriber class (see note) 


M 


- 


Encryption, air interface 


M 


M 


Handle to the request (see note) 


M 


M 


Reconnection result 


- 


M 


NOTE: Not sent over the air interface. 
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20.3.5.1.7 



TL-RELEASE primitive 



TL-RELEASE: this primitive shall be used to disconnect locally an LLC advanced link, when a disconnection is 
recognized by the service user and LLC might no longer perform a disconnection with the peer entity. 

It may also be used when the MAC has indicated that the connection on this channel has been lost. 

The parameters in this primitive shall be as defined in table 20.24. 

Table 20.24: Parameters used in the TL-RELEASE primitive 



Parameter 


Request 


Indication 


Address type (see note) 


M 


M 


Main address (see note) 


M 


M 


Link identifier (see note) 


M 


C 


Endpoint identifier (see note) 


- 


M 


NOTE: Not sent over the air interface. 



20.3.5.1.8 



TL-REPORT primitive (TLA-SAP) 



TL-REPORT indication: this primitive shall be used by the layer 2 to report to the layer 2 service user the progress or 
failure of a request procedure. The progress indication shall be passed as the "Report" parameter. This primitive may be 
issued to the layer 2 service user as an indication that an unrecoverable error has occurred. 

This primitive is also used to indicate that MAC has received a channel change command without an SDU and cannot 
decide whether it should obey the request or not as the change will affect other concurrent services. 

Parameters for this primitive shall be as defined in table 20.25. 

NOTE: The completion of the requested service is indicated by the same primitive name with the type confirm. 

Table 20.25: Parameters used in the TL-REPORT primitive (TLA-SAP) 



Parameter 


Indication 


Handle to the request (see note 1) 


C (see note 2) 


Report (see note 1) 


M 


Channel change response required (see note 1) 


C (see note 3) 


Channel change handle (see note 1) 


C (see note 3) 


Channel information 


C 


Endpoint identifier (see note 1) 


C (see note 3) 


NOTE 1 : Not sent over the air interface. 

NOTE 2: IVlandatory when data transmission is reported. 

NOTE 3: Mandatory when a channel change is reported. 
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20.3.5.1.9 



TL-UNITDATA primitive 



In the unacknowledged data transfer service the parameters for the following primitives shall be as defined in 
table 20.26 for the basic link and as defined in table 20.27 for the advanced link. 

TL-UNITDATA request: this primitive shall be used by the layer 2 service user to request layer 2 to transmit a 
TL-SDU. 

TL-UNITDATA indication: this primitive shall be used to deliver the received TL-SDU to the layer 2 service user. 

TL-UNITDATA confirm: this primitive may be used to indicate completion of sending of the requested TL-SDU. 

Table 20.26: Parameters used in the TL-UNITDATA primitive in basic link 



Parameter 


Request 


Indication 


Confirm 
(see note 2) 


Address type 


M 


M 


M 


Main address 


M 


M 


M 


Link identifier (see note 1) 


M 


M 


M 


Endpoint identifier (see note 1) 


M 


M 


M 


New endpoint identifier (see note 1) 


- 


C 


- 


CSS endpoint identifier (see note 1) 


- 


C 


- 


TL-SDU 


M 


C 


- 


TL-SDU length (see note 1) 


M 


C 


- 


Scrambling code 


M 


M 


- 


PDU priority (see note 1) 


M 


- 


- 


Stealing permission (see note 1) 


M 


- 


- 


Subscriber class (see note 1) 


M 


- 


- 


PCS flag 


M 


M 


- 


Encryption, air interface 


M 


M 


- 


Data priority (see note 3) 


M 


- 


- 


Packet data flag (see note 1 ) 


M 


- 


- 


Number of repetitions of TL-SDU 
(see note 1 ) 


C 


- 


- 


Scheduled data status (see note 1 ) 


M 


- 


- 


IVIaximum schedule interval (see note 1) 


C 


- 


- 


Data class information (see note 1) 


C 


- 


- 


Channel change response required 
(see note 1 ) 


- 


M 


- 


Channel change handle (see note 1) 


- 


C 


- 


Channel information 


- 


C 


- 


Handle to the request (see note 1) 


M 


- 


M 


Report 


- 


c 


c 


NOTE 1 : Not sent over the air interface. 

NOTE 2: In this case, the confirm is a local knowledge of the sending entity. 

NOTE 3: IVIay be signalled over the air interface, collated with other data priority information. 
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Table 20.27: Parameters used in the TL-UNITDATA primitive in advanced linl< 



Parameter 


Request 


Indication 


Confirm 
(see note 2) 


Address type 


M 


M 


M 


Main address 


M 


M 


M 


Link identifier (see note 1) 


M 


M 


M 


Endpoint identifier (see note 1) 


M 


M 


M 


New endpoint identifier (see note 1) 


- 


C 


- 


CSS endpoint identifier (see note 1) 


- 


C 


- 


TL-SDU 


M 


M 


- 


TL-SDU length (see note 1) 


M 


M 


- 


Scrambling code 


M 


M 


- 


PDU priority (see note 1) 


M 


- 


- 


Stealing permission (see note 1) 


M 


- 


- 


Subscriber class (see note 1) 


M 


- 


- 


PCS flag 


C 


C 




Encryption, air interface 


M 


M 


- 


Data class information (see note 1) 


C 


- 


- 


Channel change response required 
(see note 1 ) 


- 


M 


- 


Channel change handle (see note 1) 


- 


C 


- 


Channel information 


- 


C 


- 


Handle to the request (see note 1) 


M 


- 


M 


Report 


- 


c 


c 


NOTE 1 : Not sent over the air interface. 

NOTE 2: In this case, the confirm is a local knowledge of the sending entity. 



20.3.5.2 Signals at the TLA-SAP (MLE-LLC) 

The TLA-SAP signals (FLOW-READY signal and FLOW -NOT-READY signal) are used in the protocol description of 
the MS's message-buffering interface between the LLC service user (MLE) and LLC. As this is purely local to an MS, 
the following description is provided for information only. 

The FLOW-READY signal shall be used by the LLC service user in the MS to indicate to the LLC when it is capable 
of receiving more user data TL-SDUs in TL-DATA indication primitives. 

The FLOW-NOT -READY signal shall be used by the LLC service user in the MS to indicate to the LLC when it is 
not capable of receiving more user data TL-SDUs in TL-DATA indication primitives. 

NOTE: The validity time of one FLOW-NOT-READY signal at the LLC is limited by T.271 and T.272 in the 
sending and receiving entities respectively. 

The parameters in the flow control signal shall be: 

• address type; 

• main address; and 

• link identifier. 

The link identifier will not be sent over the air. 

20.3.5.3 Primitives at the TLB-SAP (MLE-LLC) 

In the present document the LLC layer does not have any TMB-SAP related functions. The request primitives at the 
TLB-SAP are directly mapped as request primitives at the TMB-SAP, and the indication primitives at the TMB-SAP 
are directly transported to TLB-SAP indication primitives. 
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20.3.5.3.1 TL-SYNC primitive 

TL-SYNC request: this primitive shall be used in the BS to broadcast synchronization information. 

TL-SYNC indication: this primitive shall be used in the MS to transport the received TM-SDU part of the 
synchronization information via LLC to MLE. 

The BS MAC will broadcast the information at suitable intervals. Every new request primitive may change the content 
of the broadcast information. The parameters shall be as defined in table 20.28. 

Table 20.28: Parameters used in the TL-SYNC primitive 



Parameter 


Request 


Indication 


Endpoint identifier 


M 


M 


TL-SDU 


M 


M 


TL-SDU length 


M 


M 


Priority (not sent over the air interface) 


M 


- 



20.3.5.3.2 



TL-SYSINFO primitive 



TL-SYSINFO request: this primitive shall be used in the BS to broadcast system related information needed in the 
process of cell selection on the BNCH. 

TL-SYSINFO indication: this primitive shall be used in the MS to transport the received TM-SDU via LLC to MLE. 

The BS MAC will broadcast the information at suitable intervals. Every new request primitive may change the content 
of the broadcast information. The parameters shall be as defined in table 20.29. 

Table 20.29: Parameters used in the TL-SYSINFO primitive 



Parameter 


Request 


Indication 


Endpoint identifier 


M 


M 


TL-SDU 


M 


M 


TL-SDU length 


M 


M 


MAC broadcast information 


C 


C 


Priority (not sent over the air interface) 


M 


- 



20.3.5.3.3 



TL-SYSINFO-Q primitive 



TL-SYSINFO-Q request: this primitive may be used in the BS to broadcast system related information on the 
BNCH-Q. 

TL-SYSINFO-Q indication: this primitive shall be used in the MS to transport the received TM-SDU via LLC to 
MLE. 

The BS MAC will broadcast the information at suitable intervals. Every new request primitive may change the content 
of the broadcast information. The parameters shall be as defined in table 20.30. 

Table 20.30: Parameters used in the TL-SYSINFO-Q primitive 



Parameter 


Request 


Indication 


Endpoint identifier 


M 


M 


TL-SDU 


M 


M 


TL-SDU length 


M 


M 


MAC broadcast information 


C 


C 


Priority (not sent over the air interface) 


M 


- 
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20.3.5.4 Primitives at the TLC-SAP (MLE-LLC) 

In the present document the LLC layer does not have any TLC-SAP related functions. The request and response 
primitives at the TLC-SAP are directly mapped as request and response primitives at the TMC-SAP, and the indication 
and confirm primitives at the TMC-SAP are directly transported to TLC-SAP indication and confirm primitives. 



20.3.5.4.1 



TL-ASSESSMENT primitive 



TL-ASSESSMENT indication: this primitive shall be used at the TLC-SAP to indicate the result of the assessment of 
the path loss for one or more channel classes on the serving cell. This shall be a consequence of the action started by a 
TL-ASSESSMENT-LIST request primitive. The parameters shall be as defined in table 20.31. 

Table 20.31 : Parameters used in the TL-ASSESSMENT primitive 



Parameter 


Indication (see note 1) 


Channel class label 


M 


Path loss C4 


M 


Channel class label (see note 2) 


C 


Path loss C4 (see note 2) 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: These two parameters may be repeated as a set. 



20.3.5.4.1a 



TL-ASSESSMENT-LIST primitive 



TL-ASSESSMENT-LIST request: this primitive shall be used at the TLC-SAP to start the assessment of the path loss 
for a list of channel classes on the serving cell, given as parameters. The assessment is based on measurements made on 
the current channel, together with information about the characteristics of the channel class to be assessed. The 
parameters shall be as defined in table 20.32. 

Table 20.32: Parameters used in the TL-ASSESSMENT-LIST primitive 



Parameter 


Request (see note 1) 


Channel class label 


M 


Characteristics of channel class to be 
assessed 


M 


Channel class label (see note 2) 


C 


Characteristics of channel class to be 
assessed (see note 2) 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: These two parameters may be repeated as a set. 
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20.3.5.4.1b 



TL-CONFIGURE primitive 



TL-CONFIGURE indication: this primitive shall be used to indicate when lower layer resources are lost. It may be 
used to indicate when the resources are regained. The parameters shall be as defined in table 20.33. 

TL-CONFIGURE request, confirm: this primitive shall be used to set up and configure the layer 2 according to the 
chosen cell parameters and the current state of the MS. The parameters shall be as defined in table 20.33. 

Table 20.33: Parameters used in the TL-CONFIGURE primitive 



Parameter 


Request 
(see note) 


Indication 
(see note) 


Confirm 
(see note) 


Threshold values 


C 


- 


c 


Distribution on 18th frame 


C 


- 


c 


SCCH information 


c 


- 


c 


Energy economy group 


c 


- 


c 


Energy economy startpoint 


c 


- 


c 


Dual watch energy economy group 


c 


- 


c 


Dual watch startpoint 


c 


- 


c 


IVILE activity indicator 


c 


- 


- 


Channel change accepted 


c 


- 


- 


Channel change handle 


c 


- 


- 


Operating mode 


c 


- 


c 


Call release 


c 


- 


c 


Valid addresses 


c 


- 


c 


IVIS default data priority 


c 


- 


c 


Layer 2 data priority lifetime 


c 


- 


c 


Layer 2 data priority signalling delay 


c 


- 


c 


Data priority random access delay factor 


c 


- 


c 


Schedule repetition information 


c 


- 


c 


Data class activity information 


c 


- 


c 


Endpoint identifier 


c 


M 


c 


Lower layer resource availability 


- 


M 


- 


Periodic reporting timer 





- 


- 


NOTE: Not sent over the air interface. 



20.3.5.4.2 



TL-MEASUREMENT primitive 



TL-MEASUREMENT indication: this primitive shall be used to indicate to the upper layer the quality of the link of 
the current channel on the serving cell, based on the weighted result of the measured and acquired parameters; also, if 
the MS is not on a conforming channel, it indicates the result of assessment of the path loss on the main carrier of the 
serving cell. The parameters shall be as defined in table 20.34. 

Table 20.34: Parameters used in the TL-MEASUREMENT primitive 



Parameter 


Indication (see note 1) 


Endpoint identifier 


M 


Path loss C1 


M 


Ouality indication 


C 


Path loss C3 on main carrier (see note 2) 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: Included when MS is not on a conforming channel. 
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20.3.5.4.3 



TL-MONITOR primitive 



TL-MONITOR indication: this primitive shall be used at the TLC-SAP to indicate the result of the monitoring of one 
particular RF channel; it may also indicate the result of assessment of the path loss for one or more channel classes 
(using the measurements made on the monitored RF channel). This shall be a consequence of the action started by a 
TL-MONITOR-LIST request primitive. The parameters shall be as defined in table 20.35. 

Table 20.35: Parameters used in the TL-MONITOR primitive 



Parameter 


Indication (see note 1) 


Channel number 


M 


Path loss C2 


M 


Quality indication 


C 


Channel class label 


C 


Path loss C5 


C 


Channel class label (see note 2) 


C 


Path loss C5 (see note 2) 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: These two parameters may be repeated as a set. 



20.3.5.4.4 



TL-MONITOR-LIST primitive 



TL-MONITOR-LIST request: this primitive shall be used at the TLC-SAP to start the monitoring of a list of RF 
channels given as parameters; also, in the case of a request to monitor the main carrier of a neighbour cell or the main 
carrier of the serving cell, it may request the assessment of the path loss for a list of channel classes (using the 
measurements made on the monitored RF channel). 

The listed RF channels may be on the serving cell and/or on neighbour cells, for example: 

• the main carrier of neighbour cells, in which case the higher layers (i.e. MLE) may also request the 
assessment of the path loss for a list of channel classes on that neighbour cell; and/or 

• the main carrier of the serving cell, in which case the higher layers (i.e. MLE) may also request the 
assessment of the path loss for a list of channel classes on the serving cell; and/or 

• sectored RF channels on the serving cell; and/or 

• sectored RF channels on neighbour cells. 
The parameters shall be as defined in table 20.36. 

Table 20.36: Parameters used in the TL-MONITOR-LIST primitive 



Parameter 


Request (see note 1 ) 


Channel number 


M 


Characteristics of RF channel to be monitored 


M 


Information about channel class(es) to be assessed; 




Channel class label 


C 


Characteristics of channel class to be assessed 


C 


Channel class label (see note 2) 


C 


Characteristics of channel class to be assessed (see note 2) 


C 


Channel number (see note 3) 


C 


Characteristics of RF channel to be monitored (see note 3) 


C 


Information about channel class(es) to be assessed: 




Channel class label 


c 


Characteristics of channel class to be assessed 


c 


Channel class label (see note 2) 


c 


Characteristics of channel class to be assessed (see note 2) 


c 


NOTE 1 : Not sent over the air interface. 
NOTE 2: These two parameters may be repeated as a set. 

NOTE 3: These two parameters, together with the optional information about channel class(es) to be 
assessed, may be repeated as a set. 
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20.3.5.4.5 



TL-REPORT primitive (TLC-SAP) 



TL-REPORT indication: this primitive shall be used to report locally to the MLE about the status of an action 
undertaken at the reception of a request primitive. It may also be used to report usage marker mismatch, downlink 
failure, uplink failure or when the maximum path delay has been exceeded. It is used to give schedule timing prompts to 
the higher layers. It may also be used to report that a channel replacement is advisable or may be beneficial, or that the 
current channel performance is acceptable. The parameters shall be as defined in table 20.37. 

Table 20.37: Parameters used in the TL-REPORT primitive (TLC-SAP) 



Parameter 


Indication (see note 1) 


Handle to the request 


C 


Report 


M 


Endpoint identifier 


C (see note 2) 


NSAPI 


C (see note 3) 


NOTE 1 : Not sent over the air interface. 

NOTE 2: Used to identify concurrent IVIAC resources. 

NOTE 3: Used to identify the NSAPI to which a schedule timing prompt applies. 



20.3.5.4.6 



TL-SCAN primitive 



TL-SCAN request, confirm: this primitive shall be used at the TLC-SAP to start the scanning of a defined RF channel 
given as a parameter, together with the type of scanning (interrupting or not). It may also request the assessment of the 
path loss for a list of channel classes on the scanned cell (using the measurements made on the scanned RF channel). 
The parameters shall be as defined in table 20.38. 

Table 20.38: Parameters used in the TL-SCAN primitive 



Parameter 


Request 
(see note 1 ) 


Confirm 
(see note 1 ) 


Channel number 


M 


M 


Scanning measurement method 


M 


M 


Threshold level 


C 


M 


Report 


- 


M 


Channel class label 


C 


C 


Characteristics of channel class to be assessed 


c 


- 


Path loss C5 


- 


c 


Channel class label (see notes 2 and 3) 


c 


c 


Characteristics of channel class to be assessed (see note 2) 


c 


- 


Path loss C5 (see note 3) 


- 


c 


NOTE 1 : Not sent over the air interface. 

NOTE 2: These two parameters may be repeated as a set in the request primitive. 

NOTE 3: These two parameters may be repeated as a set in the confirm primitive. 
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20.3.5.4.7 



TL-SCAN-REPORT primitive 



TL-SCAN-REPORT indication: this primitive shall be used at the TLC-SAP to report locally the updated 
measurement of the path loss parameter after scanning has been completed. It shall be based on the updated signal 
strength measurements. It may also indicate the result of assessment of the path loss for one or more channel classes 
(using the measurements made on the scanned RF channel). The parameters shall be as defined in table 20.39. 

Table 20.39: Parameters used in the TL-SCAN-REPORT primitive 



Parameter 


Indication 


Channel number (see note 1) 


M 


Threshold level (path loss C1) (see note 1) 


M 


Report (see note 1 ) 


C 


Channel class label 


C 


Path loss C5 


C 


Channel class label (see note 2) 


C 


Path loss C5 (see note 2) 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: These two parameters may be repeated as a set. 



20.3.5.4.8 



TL-SELECT primitive 



TL-SELECT request, indication, response, confirm: these primitives shall be used at the TLC-SAP to choose the RF 
channel onto which the radio will have to tune. The request and confirm primitives shall be used when the MLE 
instructs the MAC to change channel. The indication primitive shall be used by the MAC to inform the MLE of a 
channel change under the control of the BS. The response primitive shall be used for a cell change. The parameters shall 
be as defined in table 20.40. 

Table 20.40: Parameters used in the TL-SELECT primitive 



Parameter 


Request 


Indication 


Response 


Confirm 


Channel number (see note) 


M 


M 


M 


M 


Channel information 


- 


M 


- 


- 


Threshold level (see note) 


C 


M 


C 


M 


Main carrier number 


C 


- 


C 


C 


Report (see note) 


- 


C 


c 


C 


NOTE: Not sent over the air interface. 



NOTE: The main carrier number is generally only used for announced type 1 cell reselection when a channel 
change directs the MS to a traffic channel on a new cell. On receiving TMC-SELECT indication 
primitive, the MLE returns TMC-SELECT response primitive indicating the main carrier of the new cell 
and enabling the MAC to reference the SYNC/SYSINFO information received when it previously 
scanned that main carrier. 

20.3.5.5 Primitives at the TLE-SAP (MAC-LLC) 

In addition to the services provided to the MLE through the TLA-SAP, TLB-SAP and TLC-SAP, the LLC may provide 
an additional SAP: the TLE-SAP. This is the layer 2 signalling SAP. The LLC offers the layer 2 signalling service to 
the MAC through this SAP. 

NOTE: The following description refers to the protocol definition, but does not imply any implementation. The 
LLC-MAC boundary and TLE-SAP are internal layer boundaries defined to clarify the protocol 
description. They are not testable boundaries. 
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20.3.5.5.1 



TLE-CANCEL primitive 



TLE-CANCEL request: this primitive may be used locally for the MAC to cancel a previous request. This primitive 
shall not send messages over the air interface. The parameters shall be as defined in table 20.41. 

Table 20.41 : Parameters used in the TLE-CANCEL primitive 



Parameter 


Request 


Handle to the request (see note) 


M 


NOTE: Not sent over the air interface. 



20.3.5.5.2 



TLE-REPORT primitive 



TLE-REPORT indication: this primitive shall be used by the LLC to report to the MAC the progress or result of a 
request procedure. The progress or result indication shall be passed as the Report parameter. 

Parameters for this primitive shall be as defined in table 20.42. 

Table 20.42: Parameters used in the TLE-REPORT primitive 



Parameter 


Indication 


Handle to the request (see note) 


M 


Report (see note) 


M 


NOTE: Not sent over the air interface. 



20.3.5.5.3 TLE-UNITDATA primitive 

In the layer 2 signalling service the parameters for the following primitives shall be as defined in table 20.43. 

TLE-UNITDATA request: this primitive shall be used by the MAC to request the LLC to transmit a layer 2 signalling 

message. 

TLE-UNITDATA indication: this primitive shall be used to deliver a received layer 2 signalling message to the MAC. 

TLE-UNITDATA confirm: this primitive may be used to indicate completion of sending of the requested layer 2 
signalling message. 

Table 20.43: Parameters used in the TLE-UNITDATA primitive 



Parameter 


Request 


Indication 


Confirm 
(see note 2) 


Address type 


M 


M 


M 


Main address 


M 


M 


M 


Endpoint identifier (see note 1) 


M 


M 


M 


Layer 2 signalling message 


M 


M 


- 


Layer 2 signalling message length (see note 1) 


M 


M 


- 


Scrambling code 


M 


M 


- 


PDU priority (see note 1) 


M 


- 


- 


Stealing permission (see note 1) 


M 


- 


- 


Subscriber class (see note 1) 


M 


- 


- 


Encryption, air interface 


M 


M 


- 


Number of repetitions of layer 2 signalling message 
(see note 1) 


C 


- 


- 


Data category (see note 1 ) 


C 


- 


- 


Handle to the request (see note 1 ) 


M 


- 


M 


Report 


- 


- 


M 


NOTE 1 : Not sent over the air interface. 

NOTE 2: In this case, the confirm is a local knowledge of the sending entity. 
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20.3.6 State diagram for the basic linl< 

The state transition diagram in figure 20.2 applies to the basic link services. 



TL-DATA indication 
TL-DATA response 
TL-UNITDATA indication, 
TL-REPORT indication 



TL-DATA request 
TL-UNITDATA request 
TL-REPORT indication 




TL-REPORT indication 
TL-DATA confirm 
TL-UNITDATA confirm 



TL-REPORT indication 
TL-DATA request (high priority) 



Figure 20.2: State transition diagram in basic linit at TL-SAP 



20.3.7 State diagram for advanced link 

The state transition diagram in figure 20.3 applies to the advanced link. 

TL-DISCONNECT request 



TL-UNITDATA \[°'-^' 
indication 



f disconnect) TL-DISCONNECT confirm 
TL-REPORT indication 




TL-RECONNECT confirm 
(any failure, reject) 



TL-RELEASE request 



Figure 20.3: State transition in connection mode at lUILE-LLC SAP (advanced linic) 
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20.3.8 State diagram for the layer 2 signalling service 

The state transition diagram in figure 20.4 applies to the layer 2 signalling service. 



TLE-UNITDATA indication 



TLE-UNITDATA request 




TLE-REPORT indication 
TLE-UNITDATA confirm 



TLE-REPORT indication 



Figure 20.4: State transition diagram in layer 2 signalling service at TLE-SAP 



20.4 Services provided by the MAC 



The MAC shall provide services to higher layers in the protocol architecture via four SAPs. These are TMA-SAP, 
TMB-SAP, TMC-SAP and TMD-SAP. The first three correspond to the TLA-SAP, TLB-SAP and TLC-SAP in the 
LLC. TMD-SAP shall be used for transfer of user information in circuit mode. The MAC layer service primitives shall 
be as listed in tables 20.44 to 20.47 inclusive. 

NOTE: The following description refers to the protocol definition, but does not imply any implementation. The 
LLC -MAC boundary and TMD-SAP are internal layer boundaries defined to clarify the protocol 
description. They are not testable boundaries. 

Table 20.44: TMA-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TMA-CANCEL 


yes 


no 


no 


no 


TMA-RELEASE 


no 


yes 


no 


no 


TMA-REPORT 


no 


yes 


no 


no 


TMA-UNITDATA 


yes 


yes 


no 


no 



Table 20.45: TMB-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TMB-SYNC 


yes, BS 


yes, MS 


no 


no 


TMB-SYSINFO 


yes, BS 


yes, MS 


no 


no 


TMB-SYSINFO-Q 


yes, BS 


yes, MS 


no 


no 



Table 20.46: TMC-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TMC-ASSESSMENT 


no 


yes 


no 


no 


TMC-ASSESSMENT-LIST 


yes 


no 


no 


no 


TMC-CONFIGURE 


yes 


yes 


no 


yes 


TMC-MEASUREMENT 


no 


yes 


no 


no 


TMC-MONITOR 


no 


yes 


no 


no 


TMC-MONITOR-LIST 


yes 


no 


no 


no 


TMC-REPORT 


no 


yes 


no 


no 


TMC-SCAN 


yes 


no 


no 


yes 


TMC-SCAN-REPORT 


no 


yes 


no 


no 


TMC-SELECT 


yes 


yes 


yes 


yes 
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Table 20.47: TMD-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TMD-REPORT 


no 


yes 


no 


no 


TMD-UNITDATA 


yes 


yes 


no 


no 



20.4. 1 Services at the TMA-SAP 

The TMA-SAP shall be used for transfer of signalling and packet data information on the air interface. The TMA-SAP 
provides the following services to the LLC layer: 

• data manipulation (PDU composition/decomposition); 

• transfer of PDUs as indicated in the following clauses. 

20.4.1 .1 Service primitives at the TMA-SAP 



20.4.1.1.1 



TMA-CANCEL primitive 



TMA-CANCEL request: this primitive shall be used to cancel a TMA-UNITDATA request primitive that was 
submitted by the LLC. The parameters shall be as defined in table 20.48. 

Table 20.48: Parameters used in the TMA-CANCEL primitive 



Parameter 


Request (see note) 


Handle to the request 


M 


NOTE: Not sent over the air interface. 



20.4.1.1.2 



TMA-RELEASE primitive 



TMA-RELEASE indication: this primitive may be used when the MAC leaves a channel in order to indicate that the 
connection on that channel is lost (e.g. to indicate local disconnection of any advanced links on that channel). The 
parameters in this primitive shall be as defined in table 20.49. 

Table 20.49: Parameters used in the TMA-RELEASE primitive 



Parameter 


Indication 


Endpoint identifier (see note) 


M 


NOTE: Not sent over the air interface. 



20.4.1.1.3 



TMA-REPORT primitive 



TMA-REPORT indication: this primitive shall be used by the MAC to report on the progress or failure of a request 
procedure. The result of the transfer shall be passed as a report parameter. The parameters shall be as defined in 
table 20.50. 

Table 20.50: Parameters used in the TMA-REPORT primitive 



Parameter 


Indication (see note) 


Handle to the request 


M 


Report 


M 


NOTE: Not sent over the air interface. 
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20.4.1.1.4 TMA-UNITDATA primitive 

TMA-UNITDATA request: this primitive shall be used to request the MAC to transmit a TM-SDU. 

TMA-UNITDATA indication: this primitive shall be used by the MAC to deliver a received TM-SDU. This primitive 
may also be used with no TM-SDU if the MAC needs to inform the higher layers of a channel allocation received 
without an associated TM-SDU. 

The parameters shall be as defined in table 20.5 1 . 

Table 20.51 : Parameters used in the TMA-UNITDATA primitive 



Parameter 


Request 


Indication 


Handle to the request (see note 1 ) 


M 


- 


TM-SDU 


M 


C 


TM-SDU length (see note 2) 


M 


C 


Main address 


M 


M 


Address type 


M 


M 


Scrambling code 


M 


M 


Endpoint identifier (see note 1) 


M 


M 


New endpoint identifier (see note 1) 


- 


C 


CSS endpoint identifier (see note 1) 


- 


C 


PDU priority (see note 1) 


M 


- 


Stealing permission (see note 1) 


M 


- 


Subscriber class (see note 1) 


M 


- 


Encryption, air interface 


M 


M 


Stealing repeats flag (see note 1) 


C 


- 


Data category (see note 1) 


C 


- 


Channel change response required (see note 1) 


- 


M 


Channel change handle (see note 1) 


- 


C 


Channel information 


- 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: If the length indicates a Null PDU, then PDU priority shall be the lowest value 
and stealing shall not be permitted. 



20.4.1.2 Signals at the TMA-SAP 

The TMA-SAP signals (DATA-IN-BUFFER signal and MAC -READY signal) are used in the protocol description of 
the MS's message-buffering interface between LLC and MAC. As this is purely local to an MS, the following 
description is provided for information only. 

The DATA-IN-BUFFER signal is used by the LLC in the MS to indicate to the MAC when it has signalling messages 
to send, and to indicate the amount of data outstanding. 

The parameters in the DATA-IN-BUFFER signal are as follows: 

a) address type; 

b) main address; 

c) amount of data in LLC buffer: 

this is the total amount of outstanding data ready to be sent with this address (on the channel 
corresponding to the specified endpoint identifier), and not yet given to the MAC; 

NOTE 1 : It is the total amount of data ready to be sent with this address for both basic link and advanced link 
messages, including acknowledgements. 

d) highest stealing permission: 

this is the highest stealing permission parameter for messages in the LLC message buffer for this address 
(for the specified endpoint identifier); 
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e) PDU priority of highest priority unscheduled message: 

this is the highest PDU priority for unscheduled messages in the LLC message buffer for this address 
(for the specified endpoint identifier); 

f) if the MS supports data priority: 

the data priority of the highest data-priority message: 

■ this is the highest data priority for messages in the LLC message buffer for this address (for the 
specified endpoint identifier); 

information about type of data expected to be sent next; 

■ this indicates whether or not the next message expected to be sent with this address (on the channel 
corresponding to the specified endpoint identifier) contains packet data; 

g) if the channel corresponding to the specified endpoint identifier is a 7i/4-DQPSK channel and the MS supports 
data priority: 

amount of data in LLC buffer per data priority; 

■ this is the amount of outstanding data, for each data priority, to be sent with this address (on the 
channel corresponding to the specified endpoint identifier), and not yet given to the MAC; 

NOTE 2: When indicating the amount of outstanding data for each data priority, the LLC may include all data in its 
queue for this address and endpoint identifier (including data that is not yet ready to be sent). 

h) if the channel corresponding to the specified endpoint identifier is a D8PSK or QAM channel: 

amount of data in LLC buffer per data category; 

■ this is the amount of outstanding data, for each data category, ready to be sent with this address (on 
the channel corresponding to the specified endpoint identifier), and not yet given to the MAC; 

i) if the channel corresponding to the specified endpoint identifier is a D8PSK or QAM channel and the MS 
supports data priority: 

amount of data in LLC buffer per data category and per data priority; 

■ this is the amount of outstanding data, for each data category and data priority, to be sent with this 
address (on the channel corresponding to the specified endpoint identifier), and not yet given to the 
MAC; 

j) fully scheduled or unscheduled data information: 

this indicates whether all, some or none of the data in the LLC message buffer for this address (for the 
specified endpoint identifier) is fully scheduled data; 

k) lowest value of maximum schedule interval; 

this indicates the lowest value of the maximum schedule interval for any fully scheduled data in the LLC 
message buffer for this address (for the specified endpoint identifier); 

1) PDU priority of highest priority fully scheduled message: 

this is the highest PDU priority for fully scheduled messages in the LLC message buffer for this address 
(for the specified endpoint identifier); 

m) endpoint identifier. 

The MAC-READY signal is issued by the MAC in the MS to the LLC when the MAC is ready to send a MAC block. 
Then the LLC will usually issue a TMA-UNITDATA request primitive to the MAC, containing a TM-SDU to be sent 
in the MAC block. 
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The parameters in the MAC -READY signal are as follows: 

a) address type; 

b) main address; 

c) size of TM-SDU in this MAC block: 

this parameter is included if the MS is on a ji/4-DQPSK channel; it is the maximum size of TM-SDU that 
can be carried in the current MAC block (i.e. the maximum size without requiring fragmentation); 

d) normal advanced link segment size: 

this parameter is included if the MS is on a QAM channel; it indicates the current normal segment size 
for new advanced link data segments; 

NOTE 3: On a 25 kHz or 50 kHz QAM channel, the normal advanced link segment size is determined by the 
available space in a 4-QAM rate = Vi full-slot MAC block at the current bandwidth; on a 100 kHz or 
150 kHz QAM channel, the normal advanced link segment size is determined by the available space in 
half of a 4-QAM rate = Vi full-slot MAC block at the current bandwidth. 

e) data categories for which a normal advanced link data segment may be sent in this MAC block: 

this information is included if the MS is on a QAM channel; it indicates the data categories for which a 
normal advanced link data segment may be sent in the current MAC block; 

f) data categories for which a TM-SDU may be sent in this MAC block: 

this information is included if the MS is on a D8PSK or QAM channel; it indicates the data categories 
for which a TM-SDU may be sent in the current MAC block; 

g) size of TM-SDU per data category in this MAC block: 

this information is included if the MS is on a D8PSK channel; it indicates the maximum size of TM-SDU 
that can be carried in the current MAC block for each data category for which a TM-SDU may be sent 
(i.e. the maximum size without requiring fragmentation); 

this information should be included for some or all categories if the MS is on a QAM channel; it 
indicates the maximum size of TM-SDU that can be carried in the current MAC block for appropriate 
data categories for which a TM-SDU may be sent (i.e. the maximum size without requiring 
fragmentation); 

NOTE 4: The information in g) is needed on a D8PSK channel, for example, so that the sending LLC knows what 
advanced link segment size to use when cutting a new segment of TL-SDU. Segments may be of different 
size, depending on whether the MAC considers that 7i/4-DQPSK or ti/S-DSPSK modulation is currently 
appropriate for first transmissions of segments for this data category. 

On a QAM channel, the information in d) and e) normally enables the sending LLC to process advanced 
link segments correctly. However the information in g) is useful in some cases, for example: 

■ in order for the LLC to decide whether to use BL-ADATA or BL-ACK (see clause 22.3.2.3); or 

if the MS chooses not to fragment AL-ACK, AL-RNR, AL-X-ACK or AL-X-RNR PDUs (using 
multiple PDUs instead - see clauses 22.3.3.2.3 and 23.3.3.2a); or 

■ if the MS sends a first segment of TL-SDU in a random access message; or 

■ in order to facilitate transmissions or re-transmissions of short final segments or segment 
re-transmissions after a change of bandwidth. 

h) maximum size of TM-SDU: 

this is the maximum size of TM-SDU that can be handled in the MAC at this time (e.g. the maximum 
size of fragmented TM-SDU); 

i) endpoint identifier. 
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20.4.1 .3 Mapping of the service primitives between LLC and MAC at the TMA-SAP 

The LLC shall control the relationships between the LLC data transfer service primitives offered to the MLE and the 
data transfer service primitives offered by the MAC to the LLC. Table 20.52 shows these relationships at the TLA-SAP 
(MLE-LLC) and the TMA-SAP (LLC-MAC). 

According to the protocol model, the LLC may offer a data transfer service to the MAC through the TLE-SAP, for 
layer 2 signalling. The LLC then uses the data transfer service primitives offered by the MAC at the TMA-SAP in order 
to send or receive layer 2 signalling PDUs. The LLC shall control the relationships between the LLC data transfer 
service primitives offered to the MAC for layer 2 signalling at the TLE-SAP and the data transfer service primitives 
offered by the MAC to the LLC at the TMA-SAP. Table 20.52 shows these relationships at the TLE-SAP (MAC-LLC) 
and the TMA-SAP (LLC-MAC). 

Table 20.52: Correspondence between MAC and LLC at the TMA-SAP, TLA-SAP and TLE-SAP 



LLC Service Primitives 
(TLA-SAP and TLE-SAP) 


MAC Service Primitive (TMA-SAP) 


TL-CONNECT request 
TL-CONNECT response 
TL-DATA request 
TL-DATA response 
TL-DISCONNECT request 
TL-RECONNECT request 
TL-UNITDATA request 
TLE-UNITDATA request 


TMA-UNITDATA request 


TL-CONNECT indication 
TL-CONNECT confirm 
TL-DATA indication 
TL-DATA confirm 
TL-DISCONNECT indication 
TL-DISCONNECT confirm 
TL-RECONNECT confirm 
TL-UNITDATA indication 
TLE-UNITDATA indication 


TMA-UNITDATA indication 


TL-CANCEL request 
TLE-CANCEL request 


TIVIA-CANCEL request 


TL-RELEASE indication 


TMA-RELEASE indication 


TL-RELEASE request 


None 


TL-REPORT indication 
TLE-REPORT indication 


TMA-UNITDATA indication orTMA-REPORT 
indication or not applicable 


NOTE 1 : All tlie service primitives at the TIVIA-SAP use signalling channels (SCH or STCH), 

except for the local primitives (CANCEL, RELEASE, REPORT). 
NOTE 2: A TL-REPORT may be generated in the LLC without a report from the lower layer. 



20.4.2 Service provided at the TMB-SAP 

The TMB-SAP shall be used for the transfer of un-addressed system broadcast messages, which carry network or 
system organization information from the BS to the MS. 

In the present document the LLC layer does not have any TMB-SAP related functions. The request primitives at the 
TLB-SAP are directly mapped as request primitives at the TMB-SAP, and the indication primitives at the TMB-SAP 
are directly transported to TLB-SAP indication primitives. The service descriptions for the TLB-SAP are therefore valid 
for the TMB-SAP and are not repeated. 

Table 20.53 shows these relationships at the TLB-SAP (MLE-LLC) and the TMB-SAP (LLC-MAC). 
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Table 20.53: Correspondence between MAC and LLC at the TMB-SAP and TLB-SAP 



LLC Service Primitives (TLB-SAP) 


IMAC Service Primitive (TMB-SAP) 


MAC Logical Cliannel 
(TMV-SAP) 


TL-SYNC request, indication 


TIVIB-SYNC request, indication 


BSCH 


TL-SYSINFO request, indication 


TIVIB-SYSINFO request, indication 


BNCH (SCH/HD) 


TL-SYSINFO-Q request, indication 


TMB-SYSINFO-Q request, indication 


BNCH-Q (SCH-Q/D) 


NOTE: The received system synchronization and information messages in the IVIS are conveyed to the IVILE via 
the LLC using the TxB-SAP. Parameters calculated when receiving broadcast information are conveyed 
using the TxC-SAP. 



20.4.3 Service provided at tine TMC-SAP 



The TMC-SAP shall be used for the transfer of local layer management information. It does not provide data transfer 
services over the air interface. The request and response primitives at the TLC-SAP shall be directly mapped as request 
and response primitives at the TMC-SAP, and the indication and confirm primitives at the TMC-SAP shall be directly 
transported to the TLC-SAP as indication and confirm primitives. The service descriptions for the TLC-SAP are 
therefore valid for the TMC-SAP and are not repeated. The LLC also may use the TMC-CONFIGURE request 
primitive. 

TMC-CONFIGURE indication: this primitive shall be used to indicate loss of lower layer resources. It may be used to 
indicate regain of lower layer resources. The parameters shall be as defined in table 20.54. 

TMC-CONFIGURE request: this primitive shall be used to accept or reject a channel change. It is also used for the 
LLC to provide the MAC with information about activity. It is used for the LLC to provide the MAC with timer 
information that may be needed in the napping procedure. It may also be used for the LLC to provide the MAC with 
information that the MAC may use to make choices about link adaptation. The parameters shall be as defined in 
table 20.54. 

Table 20.54: Parameters used in the TMC-CONFIGURE request primitive 



Parameter 


Request 


Indication 


Channel change handle (see notes 1 and 2) 


C 


- 


Channel change accepted (see notes 1 and 2) 


C 


- 


MLE activity indicator (see notes 1 and 2) 


c 


- 


LLC timer status (see note 1) 


c 


- 


Link performance information (see note 1) 


c 


- 


Endpoint identifier (see note 1) 


c 


M 


Lower layer resource availability (see note 1) 


- 


M 


NOTE 1 : Not sent over the air interface. 

NOTE 2: These parameters are a subset of those TMC-CONFIGURE request parameters which 

are used when TL-CONFIGURE request primitive is mapped into TIVIC-CONFIGURE 

request primitive, refer to clause 20.3.5.4.1b. 



Table 20.55 shows relationships at the TLC-SAP (MLE-LLC) and the TMC-SAP (LLC-MAC). 

Table 20.55: Correspondence between MAC and LLC at the TMC-SAP and TLC-SAP 



LLC service primitives (TLC-SAP) 


MAC service primitive (TMC-SAP) 


TL-ASSESSMENT 


TMC-ASSESSMENT 


TL-ASSESSMENT-LIST 


TMC-ASSESSMENT-LIST 


TL-CONFIGURE 


TMC-CONFIGURE 


TL-MEASUREMENT 


TMC-MEASUREMENT 


TL-MONITOR 


TMC-MONITOR 


TL-MONITOR-LIST 


TMC-MONITOR-LIST 


TL-REPORT 


TMC-REPORT 


TL-SCAN 


TMC-SCAN 


TL-SCAN-REPORT 


TMC-SCAN-REPORT 


TL-SELECT 


TMC-SELECT 
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20.4.4 Service provided at tine TMD-SAP 

The TMD-SAP shall be used in the MS in circuit mode for the transfer of speech frames and/or synchronization 
information for end-to-end encryption purpose, and/or the transfer of data. It shall provide the interface between the 
MAC and the TETRA speech CODEC, and between the MAC and the other circuit mode applications. 

The speech frames may contain either clear or end-to-end encrypted speech, but their actual information content (as also 
for data transported in circuit mode) is irrelevant to the MAC. Speech frames may be stolen by the MAC according to 
the parameter definition and the procedures as explained in clause 23. The same parameters may be used for circuit 
mode data. 

Before transmission, speech frames and user data shall be coded and protected in the MAC in a way depending on 
whether they contain only speech or user data related information, one stolen half slot or two stolen half slots. Stolen 
half slots shall contain signalling information, either from C-plane or from U-plane (e.g. for end-to-end encryption 
s ynchroniz ation) . 

For the purpose of the description in the rest of this clause, the unit of exchange at the TMD-SAP is always a half slot. 
Under normal circumstances in traffic mode, two primitive exchanges each containing the equivalent of half a slot 
capacity are required to fill the physical MAC block going to be transmitted over the air interface. 

20.4.4.1 Service primitives and parameters at the TMD-SAP 



20.4.4.1.1 



TMD-REPORT primitive 



TMD-REPORT indication: this primitive shall be used by the MAC to report on the progress of a request procedure. 
For example, it shall be used by the sending MAC to report to the U-plane application when the MAC has stolen traffic 
capacity. 

The half slot synchronization shall be a parameter (or any local signal) that the MS MAC shall give internally to the 
U-plane application to enable a distinction between the first and the second half slot, i.e. a proper use of first half slot 
and second half parameters by the U-plane application. For the purpose of this description, a TMD-REPORT indication 
primitive shall be sent before any TMD-UNITDATA request primitive as an initial synchronization for the U-plane 
application. 

The parameters shall be as defined in table 20.56. 

Table 20.56: Parameters used in the TMD-REPORT primitive 



Parameter 


Indication (see note) 


Half slot synchronization 


C 


TCH type and interleaving depth 


C 


Number of tt/4-DQPSK slots per TDMA frame 


c 


End-to-end encryption flag 


c 


User device 


c 


Report 


M 


NOTE: Not sent over the air interface. 
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20.4.4.1 .2 TMD-UNITDATA primitive 

TMD-UNITDATA request: this primitive shall be used to request the MAC to transmit one half slot. 
TMD-UNITDATA indication: this primitive shall be used by the MAC to deliver one half slot. 
The parameters shall be as defined in table 20.57. 

Table 20.57: Parameters used in the TMD-UNITDATA primitive 



Parameter 


Request 


Indication 


Half slot content 


M 


M 


Half slot position (see note) 


C 


C 


Half slot importance (see note) 


M 


- 


Stolen indication 


M 


M 


Half slot condition (see note) 


- 


M 


User device (see note) 


C 


C 


NOTE: Not sent over the air interface. 



NOTE: The half slot position may be implicit after the first synchronization phase. 
The user device number shall identify the circuit which the information shall be transferred to, and from. 
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21 Layer 2 PDU description 



This clause describes the PDUs for the V+D air interface at layer 2. An overview of the DLL architecture can be found 
in clause 19. The sub-layer interactions between MAC and LLC are described herein by the protocol elements. 

This clause is intended to be read together with the MAC protocol (see clause 23) and LLC protocol (see clause 22). A 
detailed service description is provided in clause 20. 

Binary values are indicated in this clause by a subscript 2, thus: 101 IO2. 

21.1 DLL PDU structure 

21.1.1 DLL overhead 

The DLL overhead contains independent LLC and MAC headers. Therefore, the following description distinguishes 
first LLC overhead and then MAC overhead. Overhead shall be added by a sub-layer independently of the overhead 
attached by the other sub-layer. 

21.1.2 LLC PDU structure 

The LLC adds an LLC header to TL-SDUs to create LLC PDUs. The LLC PDU shall have the format illustrated in 
figure 21.1. 



MLE 



LLC 



TL-SDU 



LLC header 


TL-SDU 


LLC PCS 



Figure 21.1 : Construction of an LLC PDU (shown with optional FCS) 



21.1.2.1 



LLC header 



The LLC header discriminates between various PDUs, see table 21.1. The uses of the different LLC PDUs are specified 
in clause 22. 



21.1.2.2 



Format of LLC header 



The LLC PDU type illustrated in figure 21.2 is defined in clause 21.2.1. The LLC PDU type element shall have a length 
of 4 bits. The length of the LLC information structure depends on the PDU type. 



LLC header 



LLC PDU type LLC information 



TL-SDU 



Figure 21.2: General format of an LLC header before the TL-SDU content 



21.1.2.3 



LLC FCS 



For the original advanced link, and on request for the basic link or extended advanced link, the LLC shall calculate and 
add an FCS to the information being transmitted. Its size shall be 32 bits. This provides a Probability of Undetected 
Erroneous Message (PUEM) of about lO'^^ or better. This may be requested for packet data transmission whereas the 
MAC error detection mechanism (16 bits CRC) guarantees a PUEM of 10'^ only. The LLC FCS shall be placed 
immediately after the end of the TL-SDU as shown in figure 21.1. The FCS as defined in clause 22 shall be used. 
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21.1.3 MAC PDU Structure 



21.1.3.1 MAC overhead 

Each TM-SDU to be transmitted shall have a MAC header added as shown in figure 21.3. 

LLC 



MAC 



TM-SDU 



MAC Header 


TM-SDU 



Figure 21.3: General format of the MAC PDU 



21.1.3.2 



Format of the MAC header 



The MAC header enables the receiving MAC entity to identify the functions to be performed on the MAC PDU. The 
MAC type defines the structure of the MAC information. The MAC header shall have the format shown in figure 21.4. 



MAC header 



MAC type MAC address and MAC information TM-SDU 



Figure 21.4: General format of a MAC header 

Generally, the MAC header shall contain three types of element, the MAC type, the MAC address and some MAC 
information. In order to keep the overhead as small as possible, continuations and the end of fragmented data 
(MAC-FRAG and MAC-END) shall not contain any address. 

The MAC header structure enables the MAC to associate and transmit several independent MAC PDUs in one MAC 
block. Unused bits should be filled with a NULL PDU as illustrated in figure 21.5, or fill bits may be used (not shown) 
(see clause 23). 



MAC Header 1 


TM-SDU 1 


MAC Header 2 


TM-SDU 2 




NULL PDU 



21.1.3.2.1 



Figure 21.5: Association of several MAC PDUs in one MAC block 



MAC type 



The MAC type enables to distinguish between the different PDUs and the different SAPs to which the receiving MAC 
should route the TM-SDU. 



21.1.3.2.2 



MAC information 



According to the MAC type, the location and format of MAC address and information is defined in the relevant MAC 
section. 

21.1.3.2.3 MAC address 

For the layer 2 addressing particularities, refer to EN 300 392-1 [6], clause 7 and to clause 23 of the present document. 
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21.1.4 DLL PDU building 



21.1.4.1 Basic link illustration 

Figure 21.6 illustrates the method when a message (MAC header and TM-SDU) fits within the MAC block size. 



LLC header 


TL-SDU 



MAC header 


TM-SDU 



Figure 21.6: Building of DLL PDU (with no fragmentation) 

If the size of the TM-SDU exceeds the available capacity in a MAC block, MAC fragmentation shall occur as shown in 
figure 21.7. 



LLC header 



TL-SDU 



TM-SDU 



MAC header TM-SDU (start) 



MAC header TM-SDU (cont.) 



MAC header TM-SDU (end) 



Figure 21.7: IVIAC fragmentation of a long TM-SDU 

Optionally, the LLC may add a FCS as part of the TM-SDU. (This is not shown in figures 21.6 and 21.7, but is 
illustrated on figure 21.1.) The whole TM-SDU contains only a single LLC header. Therefore, if an error occurs during 
transmission, the whole TM-SDU has to be re-transmitted. This is not the case for the advanced link illustrated in 
figure 21.8. 



21.1.4.2 



Advanced link illustration 



TL-SDU 



FCS 



LLC header 



Segment 



LLC header 


Segment 



LLC header Segment 



MAC header 


TM-SDU 



MAC header 


TM-SDU 



MAC header 



TM-SDU 



Figure 21.8: Segmentation provided by the advanced link 

As opposed to fragmentation performed by the MAC, LLC segmentation shall label each segment with a sent segment 
sequence number S(S) so that each of the segments shall be uniquely identified and used as the re-transmission unit 
(selective rejection applies under the advanced link, refer to clause 22). Figure 21.8 shows that each TM-SDU has its 
own LLC header in addition to the MAC header. For the original advanced link, the LLC shall add an FCS at the end of 
the last segment; for the extended advanced link, optionally the LLC may add an FCS at the end of the last segment. 
This FCS shall be calculated over the entire TL-SDU. 
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21.1.5 PDU description format 

The following clauses contain descriptions of the LLC and MAC protocol PDUs and the information elements 
contained in the PDUs. The structure of the PDU definitions represented by the tables is as follows: 

• The information element column is the name of the element. 

• The element length column defines the length of the element in bits. 

• The element types (C/O/M) are: 

Mandatory (M): this element shall always be present and shall appear in the order shown; 

Optional (O): these elements are optional and if they are used, then they shall appear in the order shown; 

Conditional (C): this element is conditional depending on another field before that element. If this is 
used, then it shall appear in the order shown. 

NOTE: Unlike the layer 3 PDUs, layer 2 PDUs do not use any "O" bits or "P" bits to indicate the presence of 
optional fields. Whether or not optional fields are present in the PDU can be derived by context. 

• The value column denotes fixed values or a range of valid values. If this field is empty all bit combinations are 
valid. 

• The remarks column defines meanings of the values or it may contain other information on the information 
element. 

21 .2 Logical Link Control (LLC) PDUs description 

The information contained in the following PDU descriptions shall be read from top to bottom. The content within an 
information element shall start with the most significant bit (i.e. the leftmost bit shown in the information element 
descriptions) and shall continue until it reaches the least significant bit. 



21.2.1 LLC PDU types 



Table 21 .1 : Definition of LLC PDU types 



LLC PDU type 


PDU associated 


OOOO2 


BL-ADATA (without FCS) 


0001 2 


BL-DATA (witliout FCS) 


001 O2 


BL-UDATA (witliout FCS) 


0011 2 


BL-ACK (witliout FCS) 


01002 


BL-ADATA (witli FCS) 


01012 


BL-DATA (witli FCS) 


01102 


BL-UDATA (witli FCS) 


01112 


BL-ACK (witli FCS) 


10002 


AL-SETUP 


1001 2 


AL-DATA/AL-DATA-AR/AL-FINAL/AL-FINAL-AR 


10102 


AL-UDATA/AL-UFINAL 


10112 


AL-ACt</AL-RNR 


11002 


AL-RECONNECT 


11012 


Supplementary LLC PDU: the PDU associated is given by the 
supplementary LLC PDU subtype (see table 21 .3) 


11102 


Layer 2 signalling PDU: the PDU associated is given by the layer 2 
signalling PDU subtype (see table 21 .2) 


11112 


AL-DISC 



The PDU type field shall have a length of 4 bits. The PDU type values shall be according to table 21.1. The names 
reflect the functionality inside the LLC. PDUs having the same LLC PDU type values are discriminated by additional 
information elements. Basic link PDUs start with prefix BL, advanced link PDUs start with prefix AL. 
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For LLC PDU type 1 1 IO2, the PDU associated is given by the 4-bit layer 2 signalling PDU subtype field according to 
table 21.2. The name of each PDU reflects the functionality of that PDU within layer 2. 

Table 21.2: Definition of layer 2 signalling PDU subtypes for LLC PDU type IIIO2 



Layer 2 signalling 
PDU subtype 


PDU associated 


OOOO2 


L2-DATA-PRI0RITY 


0001 2 


L2-SCHEDULE-SYNC 


001 O2 


L2-LINK-FEEDBACK-C0NTR0L 


0011 2 


L2-LINK-FEEDBACK-INF0 


01002 


L2-LINK-FEEDBACK-INF0-AND-RESIDUAL-DATA-PRI0RITY 


01012 


Reserved 


01102 


Reserved 


01112 


Reserved 


10002 


Reserved 


1001 2 


Reserved 


10102 


Reserved 


10112 


Reserved 


11002 


Reserved 


11012 


Reserved 


11102 


Reserved 


11112 


Reserved 



For LLC PDU type 1101 2, the PDU associated is given by the 2-bit supplementary LLC PDU subtype field according to 
table 21.3. PDUs having the same supplementary LLC PDU subtype values are discriminated by additional information 
elements. 

Table 21.3: Definition of supplementary LLC PDU subtypes for LLC PDU type 11 01 2 



Supplementary LLC 
PDU subtype 


PDU associated 


OO2 


AL-X-DATA/AL-X-DATA-AR/AL-X-FINAL/AL-X-FINAL-AR 


OI2 


AL-X-UDATA/AL-X-UFINAL 


IO2 


AL-X-ACK/AL-X-RNR 


II2 


Reserved (see note) 


NOTE: If supplementary LLC PDU subtype 1 12 is used in future editions of tlie present 
document, it is intended tliat a sub-subtype will be defined to indicate the PDU 
associated - thereby enabling further extension of the LLC PDUs. 



21 .2.2 Basic link PDU definitions 

The following 8 PDUs are defined for the basic link: 

• BL-ACK without FCS for the acknowledgement of the previous transmission (BL-DATA or BL-ADATA); 

• BL-ACK with FCS for the acknowledgement of the previous transmission (BL-DATA or BL-ADATA); 

• BL-ADATA without FCS for acknowledgement and the transmission of acknowledged information; 

• BL-ADATA with FCS for acknowledgement and the transmission of acknowledged information; 

• BL-DATA without FCS for the transmission of acknowledged information; 

• BL-DATA with FCS for the transmission of acknowledged information; 

• BL-UDATA without FCS for the transmission of unacknowledged information; 

• BL-UDATA with FCS for the transmission of unacknowledged information. 
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21.2.2.1 BL-ACK 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



BL-ACK; 

acknowledgement and optional data transfer in basic link; 

BL-DATA or BL-ADATA; 

none; 

this PDU shall be used to acknowledge one TL-SDU. There are 2 PDUs 
defined, one without and another one with a FCS. The BL-ACK PDUs 
can carry service user data from a TL-DATA response primitive. 



The elements of BL-ACK PDU without FCS shall be as defined in table 21.4. 

The elements of BL-ACK PDU with FCS shall be as defined in table 21 .5. This PDU shall be used only if a TL-SDU is 
present. 

Table 21.4: BL-ACK PDU without FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-ACK (without FCS) 


N(R) 


1 


M 




Received TL-SDU number 


TL-SDU 


variable 







Data from TL-DATA response primitive 



Table 21.5: BL-ACK PDU with FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-ACK (with FCS) 


N(R) 


1 


M 




Received TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA response primitive 


FCS 


32 


M 




Frame Check Sequence 



21 .2.2.2 BL-ADATA 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



BL-ADATA; 

basic link (acknowledged service in connectionless mode); 

BL-DATA or BL-ADATA; 

BL-ADATA or BL-ACK; 

there are two PDUs defined, one without and another one with FCS. These 
PDUs shall be used to acknowledge one TL-SDU and send acknowledged data. 



The elements of BL-ADATA PDU without FCS shall be as defined in table 21.6. 
The elements of BL-ADATA PDU with FCS shall be as defined in table 21.7. 

Table 21.6: BL-ADATA PDU without FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-ADATA (without FCS) 


N(R) 


1 


M 




Received TL-SDU number 


N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request primitive 
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Table 21.7: BL-ADATA PDU with FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-ADATA (with FCS) 


N(R) 


1 


M 




Received TL-SDU number 


N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request primitive 


FCS 


32 


M 




Frame Check Sequence 



21 .2.2.3 BL-DATA 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



BL-DATA; 

basic link (acknowledged service in connectionless mode); 

BL-ACK or BL-ADATA; 

there are two PDUs defined, one without and another one with FCS. These 
PDUs shall be used to send acknowledged data. 



The elements of BL-DATA PDU without FCS shall be as defined in table 2L8. 
The elements of BL-DATA PDU with FCS shall be as defined in table 2L9. 

Table 21.8: BL-DATA PDU without FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-DATA (without FCS) 


N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request primitive 



Table 21.9: BL-DATA PDU with FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-DATA (with FCS) 


N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request primitive 


FCS 


32 


M 




Frame Check Sequence 



21.2.2.4 BL-UDATA 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



BL-UDATA; 

basic link (unacknowledged service in connectionless mode); 

none; 

these PDUs shall be used to send unacknowledged data. There are two 
separate PDUs having a different LLC type to indicate whether the PDU 
contains the FCS or not. 



The elements of BL-UDATA PDU without FCS shall be as defined in table 2L10. 
The elements of BL-UDATA PDU with FCS shall be as defined in table 21.11. 
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Table 21.10: BL-UDATA PDU without FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-UDATA (without FCS) 


TL-SDU 


variable 


M 




Data from TL-UNITDATA request primitive 



Table 21.11: BL-UDATA PDU with FCS contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


BL-UDATA (with FCS) 


TL-SDU 


variable 


M 




Data from TL-UNITDATA request primitive 


FCS 


32 


M 




Frame Check Sequence 



21 .2.3 Advanced link PDU definitions 

The original advanced link uses 1 1 PDUs: 

AL-ACK for an acknowledgement of received information with receive ready flow control indication; 

AL-RNR for an acknowledgement of received information with receive not ready flow control indication; 

AL-FINAL for transmission of the last segment of an acknowledged information; 

AL-FINAL-AR for transmission of the last segment of an acknowledged information with an 
acknowledgement request; 

AL-DATA for transmission of an acknowledged information segment; 

AL-DATA-AR for transmission of an acknowledged information segment with acknowledgement request; 

AL-DISC for disconnecting the advanced link; 

AL-SETUP for establishment or reset of the advanced link with quality of service negotiation; 

AL-RECONNECT for reconnection of an advanced link after cell reselection; 

AL-UDATA for transmission of a segment of an unacknowledged information; 

AL-UFINAL for transmission of the last segment of an unacknowledged information. 

NOTE 1: The 11 different PDUs are presented by 6 different LLC PDU types; see table 21.1. 

AL-DATA, AL-DATA-AR and AL-UDATA shall never contain an entire FCS and shall not be used as the last segment 
of a TL-SDU, while AL-FINAL, AL-FIN AL-AR and AL-UFINAL shall always contain a FCS or the last part of it and 
shall be used as the last segment of a TL-SDU. 

The extended advanced link uses the AL-SETUP, AL-RECONNECT and AL-DISC PDUs for establishment, reset, 
reconnection and disconnection of the advanced link. However, it uses different PDUs from the original advanced link 
for the data transmission and acknowledgements. The PDUs for data transmission and acknowledgements on the 
extended advanced link are as follows: 

AL-X-ACK for an acknowledgement of received information with receive ready flow control indication; 

AL-X-RNR for an acknowledgement of received information with receive not ready flow control indication; 

AL-X-FINAL for transmission of the last segment of an acknowledged information; 

AL-X-FINAL-AR for transmission of the last segment of an acknowledged information with an 
acknowledgement request; 

AL-X-DATA for transmission of an acknowledged information segment; 

AL-X-DATA-AR for transmission of an acknowledged information segment with acknowledgement request; 
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• AL-X-UDATA for transmission of a segment of an unacknowledged information; 

• AL-X-UFINAL for transmission of the last segment of an unacknowledged information. 

NOTE 2: These eight PDUs share a single LLC PDU type (supplementary LLC PDU) and are presented by three 
different supplementary LLC PDU subtypes; see tables 21.1 and 21.3. 

Inclusion of an PCS is optional for the extended advanced link. 

21.2.3.1 AL-ACK, AL-RNR 



PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-ACK (receiver ready with acknowledgement); 
AL-RNR (receiver not ready with acknowledgement); 

acknowledgement in original advanced link (connection mode) flow control; 

AL-DATA, AL-DATA-AR, AL-FINAL and AL-FINAL-AR; 

none; 

these PDUs shall be used to acknowledge TL-SDUs and/or segments of 
TL-SDUs sent in the original advanced link. They support flow control 
by reporting "receiver ready" or "receiver not ready" to the peer sender. 



The elements of AL-ACK and AL-RNR PDUs shall be as defined in table 21.12. 

Table 21.12: AL-ACK and AL-RNR PDUs contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-ACK and AL-RNR 


Flow control 


1 


M 





Receiver not ready (AL-RNR) 


1 


Receiver ready (AL-ACK) 


First Acknowledgement Block 


variable 


M 




Acknowledgement of the eldest 
unacknowledged TL-SDU 


Other Acknowledgement Blocks 


variable 







Acknowledgement of the next 
unacknowledged TL-SDUs; may be 
repeated up to window size N.272 
(see note) 


NOTE: When appropriate, an acknowledgement block may contain a continuation of the previous 
acknowledgement block; refer to note 4 In table 21 .13. 
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The acknowledgement block shall be as defined in table 21.13. 
Table 21.13: Acknowledgement block information element contents in AL-ACK and AL-RNR PDUs 



Information element 


Length 


Type 


Value 


Remark 


N(R) 


3 


M 




The number of the TL-SDU (see note 4) 


Acknowledgement length 


6 


M 


OOOOOO2 


SDU correctly received 


000001 2 


Number of acknowledged segments 


etc. 


etc. 


IIIIIO2 


Number of acknowledged segments 


IIIIII2 


Repeat the entire SDU 


S(R) 


8 
see note 1 


C 




Sequence number of the eldest not yet 
correctly received segment (see note 4) 


Acknowledgement bit map 


Variable 
see note 2 
see note 3 


C 





Incorrectly or not yet received segment 


1 


Correctly received segment 


NOTE 1 : The element is present if the acknowledgement length is in the range from 000001 2 to 1 1 1 1 1 02- 

NOTE 2: Length of the bit map is variable, each bit is set as defined. 

NOTE 3: The element is present if the acknowledgement length is in the range from 00001 O2 to 1 1 1 1 1 02.The 

length of the bit map is acknowledgement length minus one. 
NOTE 4: On a tt/4-DQPSK or D8PSK channel, when the maximum size of the TL-SDU is 4 096 octets, two 

acknowledgement blocks may refer to the same TL-SDU. On a QAM channel, when the available room in 
an acknowledgement block is not sufficient to indicate the reception status of the segments in a TL-SDU, 
two or more acknowledgement blocks may refer to the same TL-SDU. Thus an acknowledgement block 
may contain a continuation of the previous acknowledgement block, in which case the N{R) shall indicate 
the same number of the TL-SDU as in the previous acknowledgement block and the S(R) shall indicate 
the sequence number of the eldest not yet correctly received segment after the segments indicated by the 
previous acknowledgement block. 



The correct reception of an entire TL-SDU shall be indicated by the acknowledgement length set to zero (OOOOOO2). A 
TL-SDU FCS failure shall be indicated by the acknowledgement length set to 11 11 II2 binary. In these cases the 
acknowledgement block shall not contain the fields S(R) and acknowledgement bit map. 

In the other cases the total number of the acknowledged segments shall be equal to the number in the acknowledgement 
length field. The "total number of the acknowledgement segments" refers to the number of segments, which are 
incorporated into the acknowledgement PDU. In the case of OOOOOI2 binary, only S(R) is present and the bit map is 
empty. Because the segment indicated by S(R) is implicitly not acknowledged (not correctly received), the length of the 
bit map is Acknowledgement length minus one. Acknowledgement bit map shall indicate the reception status 
(STATUS) of each segment starting from the next segment after the S(R) and moving forwards one segment at a time, 
up to the segment with the highest sequence number that has been correctly received or by the available room in the 
AL-ACK or AL-RNR PDU. The status of the segment shall be set to "1" if it is correcdy received and to "0" if it is not 
correctly received. All segments prior to the one referred to by the S(R) shall be correctly received in the indicated 
TL-SDU except when more than one acknowledgement block refers to the same TL-SDU, see note 4 in table 21.13. 
When more than one acknowledgement block refers to the same TL-SDU in the same AL-ACK or AL-RNR PDU, there 
may be a range of correctly received segments between the segments indicated in the acknowledgement blocks. 

On a 7I/4-DQPSK or D8PSK channel, when the maximum size of the TL-SDU is 2 048 octets or less, then two 
acknowledgement blocks in the same AL-ACK or AL-RNR PDU shall not refer to the same TL-SDU. 

For the sending entity on a 7i/4-DQPSK or D8PSK channel, the support of two acknowledgement blocks which refer to 
the same TL-SDU, in the same AL-ACK or AL-RNR PDU, is mandatory when it supports 4 096 octets as the 
maximum size of the TL-SDU. 

For the sending entity on a QAM channel, the support of more than one acknowledgement block which refers to the 
same TL-SDU, in the same AL-ACK or AL-RNR PDU, is mandatory. 

NOTE 1 : Instead of using more than one acknowledgement block which refers to the same TL-SDU in the same 
AL-ACK or AL-RNR PDU, the acknowledging entity may wait for re-reception of the incorrectly 
received segments before including further segments into the acknowledgements. 
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NOTE 2: If use of multiple acknowledgement blocks which refer to the same TL-SDU in the same AL-ACK or 
AL-RNR PDU would result in fragmentation of the AL-ACK or AL-RNR PDU, the acknowledging 
entity may send multiple AL-ACK or AL-RNR PDUs instead. 

The AL-ACK or AL-RNR PDU may also contain acknowledgement for multiple TL-SDUs being sent on this advanced 
link. The AL-ACK or AL-RNR PDU contains acknowledgement blocks up to the number of the TL-SDUs in the 
window for this advanced link. 

21 .2.3.1 a AL-X-ACK, AL-X-RNR 



PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-X-ACK (receiver ready with acknowledgement); 
AL-X-RNR (receiver not ready with acknowledgement); 

acknowledgement in extended advanced link (connection mode) flow control; 

AL-X-DATA, AL-X-DATA-AR, AL-X-FINAL and AL-X-FINAL-AR; 

none; 

these PDUs shall be used to acknowledge TL-SDUs and/or segments of 
TL-SDUs sent in an extended advanced link. They support flow control 
by reporting "receiver ready" or "receiver not ready" to the peer sender. 



The elements of AL-X-ACK and AL-X-RNR PDUs shall be as defined in table 2L 14. 

Table 21.14: AL-X-ACK and AL-X-RNR PDUs contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Supplementary LLC PDU 


Supplementary LLC PDU subtype 


2 


M 


see table 21.3 


AL-X-ACK and AL-X-RNR 


Flow control 


1 


M 





Receiver not ready (AL-X-RNR) 


1 


Receiver ready (AL-X-ACK) 


Advanced link number 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


Link feedback information flag 


1 


M 





"Link feedback information" information 
element not present 


1 


"Link feedback information" information 
element present 


Link feedback information 
(see note 1) 


13 


C 




See table 21.16 


First Acknowledgement Block 


variable 


M 




Acknowledgement of the eldest 
unacknowledged TL-SDU 


Other Acknowledgement Blocks 


variable 







Acknowledgement of the next 
unacknowledged TL-SDUs; may be 
repeated up to window size N.272 
(see note 2) 


NOTE 1 : This element shall be present only if the link feedback information flag is set to 1 . 
NOTE 2: An acknowledgement block may contain a continuation of the previous acknowledgement block; refer to 
note 4 in table 21.15. 
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The acknowledgement block shall be as defined in table 21.15. 

Table 21.15: Acknowledgement block information element contents 
in AL-X-ACK and AL-X-RNR PDUs 



Information element 


Length 


Type 


Value 


Remark 


N(R) 


5 


M 




The number of the TL-SDU (see note 4) 


Acknowledgement length 


6 


M 


OOOOOO2 


SDU correctly received 


000001 2 


Number of acknowledged segments 


etc. 


etc. 


IIIIIO2 


Number of acknowledged segments 


IIIIII2 


Repeat the entire SDU 


S(R) 


8 
see note 1 


C 




Sequence number of the eldest not yet 
correctly received segment (see note 4) 


Acknowledgement bit map 


Variable 
see note 2 
see note 3 


C 





Incorrectly or not yet received segment 


1 


Correctly received segment 


NOTE 1 : The element is present if the acknowledgement length is in the range from 000001 2 to 1 1 1 1 1 02- 

NOTE 2: Length of the bit map is variable, each bit is set as defined. 

NOTE 3: The element is present if the acknowledgement length is in the range from 00001 O2 to 1 1 1 1 1 02.The 

length of the bit map is acknowledgement length minus one. 
NOTE 4: When the available room in an acknowledgement block is not sufficient to indicate the reception status of 
the segments in a TL-SDU, more than one acknowledgement block may refer to the same TL-SDU. Thus 
an acknowledgement block may contain a continuation of the previous acknowledgement block, in which 
case the N(R) shall indicate the same number of the TL-SDU as in the previous acknowledgement block 
and the S(R) shall indicate the sequence number of the eldest not yet correctly received segment after 
the segments indicated by the previous acknowledgement block. 



The "link feedback information" information element (if included) shall be as defined in table 21.16. 
Table 21.16: "Link feedback information" information element contents 



Information element 


Length 


Type 


Value 


Remark 


Channel metric type 


3 


M 


OOO2 


Bit rate feedback 


001 2 


Eg/No feedback 


01 O2 


Reserved 


etc. 


etc. 


III2 


Reserved 


Bit rate feedback information 
(see note 1 ) 


10 


C 




See "bit rate feedback information" information 
element definition 


Eg/No feedback information 
(see note 2) 


10 


C 




See "Eg/No feedback Information" information 
element definition 


Reserved (see note 3) 


10 


c 


OOOOOOOOOO2 


Not used in the present document 


etc. 


etc. 


IIIIIIIIII2 


Not used in the present document 


NOTE 1 : This element shall be present only in the case of bit rate feedback i.e. channel metric type element set 

to OOO2. 

NOTE 2: This element shall be present only in the case of Ej/Nq feedback i.e. channel metric type element set to 001 2. 
NOTE 3: This element shall be present only in the case of channel metric type element greater than 001 2- It is not used 
in the present document. 



The correct reception of an entire TL-SDU shall be indicated by the acknowledgement length set to zero (OOOOOO2). A 
TL-SDU FCS failure shall be indicated by the acknowledgement length set to 11 11 II2 binary. In these cases the 
acknowledgement block shall not contain the fields S(R) and acknowledgement bit map. 
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In the other cases the total number of the acknowledged segments shall be equal to the number in the acknowledgement 
length field. The "total number of the acknowledgement segments" refers to the number of segments, which are 
incorporated into the acknowledgement PDU. In the case of OOOOOI2 binary, only S(R) is present and the bit map is 
empty. Because the segment indicated by S(R) is implicitly not acknowledged (not correctly received), the length of the 
bit map is Acknowledgement length minus one. Acknowledgement bit map shall indicate the reception status 
(STATUS) of each segment starting from the next segment after the S(R) and moving forwards one segment at a time, 
up to the segment with the highest sequence number that has been correctly received or by the available room in the 
AL-X-ACK or AL-X-RNR PDU. The status of the segment shall be set to "1" if it is correctly received and to "0" if it is 
not correctly received. All segments prior to the one referred to by the S(R) shall be correctly received in the indicated 
TL-SDU except when more than one acknowledgement block refers to the same TL-SDU, see note 4 in table 21.15. 
When more than one acknowledgement block refers to the same TL-SDU in the same AL-X-ACK or AL-X-RNR PDU, 
there may be a range of correctly received segments between the segments indicated in the acknowledgement blocks. 

For the sending entity, the support of more than one acknowledgement block which refers to the same TL-SDU, in the 
same AL-X-ACK or AL-X-RNR PDU, is mandatory. 

NOTE 1 : Instead of using more than one acknowledgement block which refers to the same TL-SDU in the same 
AL-X-ACK or AL-X-RNR PDU, the acknowledging entity may wait for re-reception of the incorrectly 
received segments before including further segments into the acknowledgements. 

NOTE 2: If use of multiple acknowledgement blocks which refer to the same TL-SDU in the same AL-X-ACK or 
AL-X-RNR PDU would result in fragmentation of the AL-X-ACK or AL-X-RNR PDU, the 
acknowledging entity may send multiple AL-X-ACK or AL-X-RNR PDUs instead. 

The AL-X-ACK or AL-X-RNR PDU may also contain acknowledgement for multiple TL-SDUs being sent on this 
extended advanced link. The AL-X-ACK or AL-X-RNR PDU contains acknowledgement blocks up to the number of 
the TL-SDUs in the window for this advanced link. 

21 .2.3.2 AL-FINAL, AL-FINAL-AR 

• PDU: AL-FINAL (last data of a TL-SDU); 

AL-FINAL-AR (last data of a TL-SDU with immediate 
acknowledgement required); 

• service provided: data transfer in original advanced link (connection mode); 

• response to: -; 

• response expected: AL-ACK to the AL-FINAL-AR; 

• short description: these PDUs shall be used to send the last segment in a TL-SDU or a whole 

TL-SDU in the original advanced link. When an immediate response is 
required, AL-FINAL-AR shall be used. 

The elements of AL-FINAL and AL-FINAL-AR PDUs shall be as defined in table 2L17. 
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Table 21.17: AL-FINAL and AL-FINAL-AR PDUs contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-DATA, AL-DATA-AR, AL-FINAL and 
AL-FINAL-AR 


FINAL 


1 


M 


1 


Last segment with FCS (AL-FINAL and 
AL-FINAL-AR) 


AR 


1 


M 





No immediate response (AL-FINAL) 


1 


Immediate response required (AL-FINAL-AR) 


N(S) 


3 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


The last segment of 
TL-DATA SDU 


Variable 
see note 1 







The last segment of TL-DATA SDU 


FCS 


32 
see note 2 


M 




Frame Check Sequence 


NOTE 1 : This PDU may contain no data from the TL-DATA request primitive, see note 2. 
NOTE 2: The size shown is the upper limit of the FCS field; a part of the FCS could be in the previous 
AL-DATA PDU. 



21 .2.3.2a AL-X-FINAL, AL-X-FINAL-AR 



PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-X-FINAL (last data of a TL-SDU); 
AL-X-FINAL-AR (last data of a TL-SDU with immediate 
acknowledgement required); 

data transfer in extended advanced link (connection mode); 



AL-X-ACK to the AL-X-FINAL-AR; 

these PDUs shall be used to send the last segment in a TL-SDU or a whole 
TL-SDU in an extended advanced link. When an immediate response is 
required, AL-X-FINAL-AR shall be used. 



The elements of AL-X-FINAL and AL-X-FINAL-AR PDUs shall be as defined in table 21.18. 
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Table 21.18: AL-X-FINAL and AL-X-FINAL-AR PDUs contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Supplementary LLC PDU 


Supplementary LLC PDU 
subtype 


2 


M 


see table 21 .3 


AL-X-DATA, AL-X-DATA-AR, AL-X-PINAL and 
AL-X-PINAL-AR 


FINAL 


1 


M 


1 


Last segment, optionally with PCS 
(AL-X-PINAL and AL-X-PINAL-AR) 


AR 


1 


M 





No immediate response (AL-X-PINAL) 


1 


Immediate response required 
(AL-X-PINAL-AR) 


Advanced link number 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


N(S) 


5 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


PCS flag 


1 


M 





No PCS 


1 


PCS used 


The last segment of 
TL-DATA SDU 


Variable 
see note 1 







The last segment of TL-DATA SDU 


PCS 


32 
see note 2 


C 




Prame Check Sequence. 
Included when PCS flag is set to 1 


NOTE 1 : This PDU may contain no data from the TL-DATA request primitive. This may occur in some cases when 
the PCS is used, see note 2. It may also occur occasionally even if the PCS is not used. 

NOTE 2: The size shown is the upper limit of the PCS field (when used); a part or all of the PCS could be in the 
previous AL-X-DATA PDU. 



The LLC header of AL-X-FINAL and AL-X-FINAL-AR is one bit longer than the LLC header of AL-X-DATA and 
AL-X-DATA-AR. Therefore there are occasional cases when the last part of the TL-SDU (and FCS when used) just fits 
within an AL-X-DATA or AL-X-DATA-AR PDU but would not fit within an AL-X-FINAL or AL-X-FINAL-AR 
PDU. In these cases, the sending entity should send the last part of the TL-SDU (and FCS when used) within an 
AL-X-DATA or AL-X-DATA-AR PDU and then send an empty AL-X-FINAL or AL-X-FINAL-AR PDU 
(i.e. containing no information after the FCS flag) to complete the TL-SDU transmission. 



21.2.3.3 

PDU: 



AL-DATA, AL-DATA-AR 



service provided: 
response to: 
response expected: 
short description: 



AL-DATA (acknowledged information transfer); 

AL-DATA-AR (acknowledged information transfer with immediate response); 

data transfer in original advanced link (connection mode); 



AL-ACK to the AL-DATA-AR; 

these PDUs shall be used to send all other segments than the last one of 
a TL-SDU in the original advanced link. When the sending entity requests 
an immediate acknowledgement, AL-DATA-AR shall be used. For the 
transmission of the last segment, see AL-FINAL/AL-FINAL-AR PDU. 



The elements of AL-DATA and AL-DATA-AR PDUs shall be as defined in table 2L19. 
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Table 21.19: AL-DATA and AL-DATA-AR PDUs contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-DATA, AL-DATA-AR, AL-FINAL and 
AL-FINAL-AR 


FINAL 


1 


M 





Not the last segment (AL-DATA and 
AL-DATA-AR) 


AR 


1 


M 





No immediate response (AL-DATA) 


1 


Immediate response required (AL-DATA-AR) 


N(S) 


3 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Segment of TL-SDU 


Varies 


M 




A segment of TL-SDU. The length depends 
on the IVIAC block used (see clause 21 .3.2). 



21.2.3.3a 

• PDU: 



AL-X-DATA, AL-X-DATA-AR 



service provided: 
response to: 
response expected: 
short description: 



AL-X-DATA (acknowledged information transfer); 
AL-X-DATA-AR (acknowledged information transfer with immediate 
response); 

data transfer in extended advanced link (connection mode); 



AL-X-ACK to the AL-X-DATA-AR; 

these PDUs shall be used to send all other segments than the last one of 
a TL-SDU in an extended advanced link. When the sending entity requests 
an immediate acknowledgement, AL-X-DATA-AR shall be used. For the 
transmission of the last segment, see AL-X-FIN AL/AL-X-FINAL-AR PDU. 

The elements of AL-X-DATA and AL-X-DATA-AR PDUs shall be as defined in table 21.20. 
Table 21.20: AL-X-DATA and AL-X-DATA-AR PDUs contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Supplementary LLC PDU 


Supplementary LLC PDU 
subtype 


2 


M 


see table 21.3 


AL-X-DATA, AL-X-DATA-AR, AL-X-FINAL 
and AL-X-FINAL-AR 


FINAL 


1 


M 





Not the last segment (AL-X-DATA and 
AL-X-DATA-AR) 


AR 


1 


M 





No immediate response (AL-X-DATA) 


1 


Immediate response required 
(AL-X-DATA-AR) 


Advanced link number 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


N(S) 


5 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Segment of TL-SDU 


Varies 


M 




A segment of TL-SDU. The length depends 
on the MAC block used (see clause 21 .3.2). 
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21.2.3.4 AL-DISC 

PDU: 

service provided: 
response to: 
response expected: 
short description: 
The elements of AL-DISC PDU 



AL-DISC (disconnection phase of the advanced link); 
disconnection of an advanced link (connection mode); 
AL-DISC, see protocol definition for parameters; 
AL-DISC or none, see protocol definition for parameters; 
this PDU is used to disconnect an advanced link, 
shall be as defined in table 21.21. 

Table 21.21 : AL-DISC PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-DISC 


Advanced link service 


1 


M 





Unacknowledged service 


1 


Acknowledged service 


Advanced linl< number 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


Report 


3 


M 


OOO2 


Success 


001 2 


Close 


01 O2 


Reject 


0112 


Service not supported 


1002 


Service temporarily unavailable 


1012 


Reserved 


1102 


Reserved 


1112 


Reserved 



The advanced link number is used locally between MS and BS to distinguish concurrent advanced links. The link 
identifier in the MLE primitives is mapped against an advanced link number. 

21.2.3.4a AL-RECONNECT 



PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-RECONNECT; 

reconnection of advanced link after cell reselection; 

AL-RECONNECT, see protocol definition for parameters; 

AL-RECONNECT, see protocol definition for parameters; 

this PDU is used by the MS to request that an advanced link which 
was used on the previous cell is reconnected on the current cell and all 
the advanced link parameters are maintained. 



The elements of AL-RECONNECT PDU shall be as defined in table 21.22. 
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Table 21.22: AL-RECONNECT PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-RECONNECT 


Advanced link service 


1 


M 





Unacknowledged service (see note) 


1 


Acknowledged service 


Advanced link number N.261 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


Reconnect report 


2 


M 


OO2 


Propose 


OI2 


Reject 


IO2 


Accept 


II2 


Reserved 


NOTE: The present document does not support reconnection of an unacknowledged advanced link. 



21.2.3.5 AL-SETUP 
PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-SETUP (acknowledged or unacknowledged information containing 
advanced link set-up parameters); 

advanced link establishment or reset; 

AL-SETUP in point-to-point case, see protocol; 

AL-SETUP or none in point-to-multipoint case, see protocol; 

this PDU is used to establish the advanced link and to reset an established 
advanced link. 



The elements of AL-SETUP PDU shall be as defined in table 2L23. 
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Table 21.23: AL-SETUP PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-SETUP 


Advanced link service 


1 


M 





Unacknowledged service 


1 


Acknowledged service 


Advanced linl< number N.261 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


IVIaximum length of a TL-SDU 
N.271 


3 


M 


OOO2 


32 octets 


001 2 


64 octets 


01 O2 


1 28 octets 


0112 


256 octets 


1002 


512 octets 


1012 


1 024 octets 


1102 


2 048 octets 


1112 


4 096 octets 


Connection width 


1 


M 





Single-slot tt/4-DQPSK connection, or no 
information about radio resources 


1 


Multislot TT/4-DQPSK connection 


Advanced link symmetry 


1 


M 





Symmetric tt/4-DQPSK advanced link, or 
no information about radio resources 


1 


Asymmetric tt/4-DQPSK advanced link 


Number of tt/4-DQPSK timeslots 
used per TDIVIA frame on uplink 
or on uplink and downlink N.264 
(see note 1) 


2 


C 


002 


1 timeslot 


012 


2 timeslots 


102 


3 timeslots 


112 


4 timeslots 


Number of tt/4-DQPSK timeslots 
used per TDMA frame on 
downlink N.264 (see note 2) 


2 


C 


002 


1 timeslot 


012 


2 timeslots 


102 


3 timeslots 


112 


4 timeslots 


Data transfer throughput 
(mean value) (see note 3) 


3 


M 


0002 


Network dependent minimum 


001 2 


1/32 of maximum 


01 O2 


1/16 of maximum 


0112 


1/8 of maximum 


1002 


1/4 of maximum 


1012 


1/2 of maximum 


1102 


No information about radio resources 


1112 


Maximum 


TL-SDU window size N.272 or 
N.281 (see note 4) 


2 


M 


002 


Augmented AL-SETUP 


012 


SDU window size = 1 


102 


SDU window size = 2 


112 


SDU window size = 3 


Maximum number of TL-SDU 
retransmissions N.273 or TL-SDU 
repetition N.282 (see note 5) 


3 


M 


0002 


no retransmissions 


001 2 


1 retransmission 


etc. 


etc. 


III2 


7 retransmissions 


Maximum number of segment 
retransmissions N.274 


4 


M 


OOOO2 


no retransmissions 


OOOI2 


1 retransmission 


etc. 


etc. 


IIII2 


15 retransmissions 
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Information element 


Length 


Type 


Value 


Remark 


Set-up report 


3 


M 


OOO2 


Success 


001 2 


Service definition 


01 O2 


Service change 


0112 


Reset 


1002 


Reserved 


1012 


Reserved 


1102 


Reserved 


1112 


Reserved 


N(S) (see note 6) 


8 


C 




Sent TL-SDU number 


Advanced link type 
(see notes 7 and 8) 


1 


C 





Original advanced link 


1 


Extended advanced link 


TL-SDU window size N.272 or 
N.281 for original advanced link 
using augmented AL-SETUP 
(see notes 4 and 9) 


2 


C 


002 


Reserved 


012 


SDU window size = 1 


102 


SDU window size = 2 


112 


SDU window size = 3 


TL-SDU window size N.272 or 
N.281 for extended advanced link 
(see notes 4 and 10) 


4 


C 


00002 


Reserved 


00012 


SDU window size = 1 


etc. 


etc. 


IIII2 


SDU window size = 15 


Reserved (see note 7) 


3 


C 


OOO2 


Default value 


001 2 


Not used in the present document 


etc. 


etc. 


III2 


Not used in the present document 


NOTE 1 : This element shall be present only for the multislot tt/4-DQPSK connection (i.e. Connection width element 

set to "1 "). In case of symmetric tt/4-DQPSK advanced link this element defines the number of tt/4-DQPSK 

timeslots used per TDMA frame both in uplink and downlink. 
NOTE 2: This element shall be present only for the multislot tt/4-DQPSK connection and asymmetric tt/4-DQPSK 

advanced link (i.e. Connection width element set to "1 " and Advanced link symmetry element set to "1 "). 

The usage of asymmetric tt/4-DQPSK advanced link is outside the scope of the present document. 
NOTE 3: The BS may use a control channel as a general packet data channel, supporting advanced links for many 

MSs, where each MS may be offering/receiving data packets at a low rate or intermittently. 

When the Data transfer throughput element is not set to 1 1 02, it gives the BS the necessary information for 

planning its resource allocations. When the Data transfer throughput element is set to 1 1 02, the AL-SETUP 

PDU provides no information relating to radio resources, in which case the BS should use the throughput 

information negotiated by the SNDCP during PDP context activation. 
NOTE 4: TL-SDU window sizes N.272 and N.281 are for the acknowledged and unacknowledged services 

respectively. 
NOTE 5: For the acknowledged service N.273 defines how many times the TL-SDU may be re-transmitted and, for 

the unacknowledged (point-to-multipoint) service, N.282 means the number of times the TL-SDU will be 

repeated by the sender. 
NOTE 6: This element shall be present only for the unacknowledged service (i.e. advanced link service element set 

to "0"). 
NOTE 7: This element shall be present only for an augmented AL-SETUP (i.e. TL-SDU window size element set 

to OO2). 
NOTE 8: In the present document there is no reason to use an augmented AL-SETUP for the original advanced link; 

however, the possibility is supported in order that the Reserved element can be used in the future for both 

types of advanced link. An augmented AL-SETUP is needed in the case of an extended advanced link. 
NOTE 9: This element shall be present only for an augmented AL-SETUP for the original advanced link (i.e. TL-SDU 

window size element set to OO2 and Advanced link type element set to "0"). 
NOTE 10: This element shall be present only for an augmented AL-SETUP for an extended advanced link (i.e. 

TL-SDU window size element set to OO2 and Advanced link type element set to "1 "). 



The advanced link number is used locally between MS and BS to distinguish concurrent advanced links. The link 
identifier in the MLE primitives is mapped against an advanced link number. 
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The AL-SETUP PDU may contain information related to radio resources (for example, if QoS information has not been 
negotiated by the SNDCP during PDP context activation). This facility in the AL-SETUP PDU provides radio resource 
information only in terms of 3i/4-DQPSK timeslots. Inclusion of this information is indicated by setting the "Data 
transfer throughput" element to a value other than IIO2. Then the combination of the "Connection width", "Advanced 
link symmetry", "Number of 7i/4-DQPSK timeslots used per TDMA frame on uplink or on uplink and downlink" and 
"Number of 3i/4-DQPSK timeslots used per TDMA frame on downlink" elements indicate the requested radio resources 
in terms of 7i/4-DQPSK timeslots. The "Data transfer throughput" element indicates how much of the total throughput 
of the requested radio resources (3i/4-DQPSK timeslots) should be available for the advanced link. Maximum 
throughput will be realized when there is only one MS using the whole capacity of the radio resource allocation. The 
lower values indicate that the same radio resources may be used for multiple advanced links for one or more MSs. The 
values are mean values and the usage allocation during the lifetime of an advanced link is outside of the scope of the 
present document. 

Alternatively (for example, if QoS information has been negotiated by the SNDCP during PDP context activation), the 
AL-SETUP PDU may provide no information related to radio resources. This is indicated by setting the "Data transfer 
throughput" element to 1 IO2, in which case the "Connection width" element and "Advanced link symmetry" element 
should be set to "0". 

Values OI2, IO2, and II2 in the TL-SDU window size element indicate the SDU window size. Value OO2 in the TL-SDU 
window size element indicates that this is an augmented AL-SETUP. In this case the following conditional elements 
shall be included: 

• advanced link type; 

• TL-SDU window size for original or extended advanced link using augmented AL-SETUP; and 

• a reserved element. 

If the AL-SETUP is not augmented, the recipient shall assume that the AL-SETUP is for the original advanced link. 



21.2.3.6 AL-UDATA 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-UDATA (unacknowledged information transfer); 
unacknowledged data transfer in original advanced link; 

none; 

this PDU is used to send one segment of unacknowledged TL-SDU in 
the original advanced link. 



The elements of AL-UDATA PDU shall be as defined in table 2L24. 

Table 21.24: AL-UDATA PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-UDATA and AL-UFINAL 


FINAL 


1 


M 





Not the last segment (AL-UDATA) 


N(S) 


8 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Segment of TL-UNITDATA 


Variable 


M 




Segment of TL-UNITDATA 
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21.2.3.6a AL-X-UDATA 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-X-UDATA (unacknowledged information transfer); 
unacknowledged data transfer in extended advanced link; 

none; 

this PDU is used to send one segment of unacknowledged TL-SDU in 
an extended advanced link. 



The elements of AL-X-UDATA PDU shall be as defined in table 2L25. 



Table 21.25: AL-X-UDATA PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Supplementary LLC PDU 


Supplementary LLC PDU subtype 


2 


M 


see table 21.3 


AL-X-UDATA and AL-X-UFINAL 


FINAL 


1 


M 





Not the last segment (AL-X-UDATA) 


Advanced link number 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


N(S) 


8 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Segment of TL-UNITDATA 


Variable 


M 




Segment of TL-UNITDATA 



21.2.3.7 AL-UFINAL 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-UFINAL (unacknowledged information transfer); 
unacknowledged data transfer in original advanced link; 

none; 

this PDU is used to send the last segment of an unacknowledged TL-SDU in 
the original advanced link. 



The elements of AL-UFINAL PDU shall be as defined in table 2L26. 

Table 21.26: AL-UFINAL PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


AL-UDATA and AL-UFINAL 


FINAL 


1 


M 


1 


Last segment with FCS (AL-UFINAL) 


N(S) 


8 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Last segment of 
TL-UNITDATA 


Variable 
see note 1 







Last segment of TL-UNITDATA 


FCS 


32 
see note 2 


M 




Frame Check Sequence 


NOTE 1 : This PDU may contain no data from the TL-UNITDATA request primitive, see note 2. 
NOTE 2: The size shown is the upper limit of the FCS field; a part of the FCS could be in the previous 
AL-UDATA PDU. 
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21.2.3.7a AL-X-UFINAL 

PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-X-UFINAL (unacknowledged information transfer); 
data transfer in extended advanced link; 

none; 

this PDU is used to send the last segment of an unacknowledged TL-SDU in 
an extended advanced link. 



The elements of AL-X-UFINAL PDU shall be as defined in table 21.27. 



Table 21.27: AL-X-UFINAL PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Supplementary LLC PDU 


Supplementary LLC PDU subtype 


2 


M 


see table 21.3 


AL-X-UDATA and AL-X-UFINAL 


FINAL 


1 


M 


1 


Last segment, optionally with FCS 
(AL-X-UFINAL) 


Advanced link number 


2 


M 


OO2 


Advanced link number 1 


OI2 


Advanced link number 2 


IO2 


Advanced link number 3 


II2 


Advanced link number 4 


N(S) 


8 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


FCS flag 


1 


M 





No FCS 


1 


FCS used 


Last segment of TL-UNITDATA 


Variable 
see note 1 







Last segment of TL-UNITDATA 


FCS 


32 
see note 2 


C 




Frame Check Sequence. 
Included when FCS flag is set to 1 


NOTE 1 : This PDU may contain no data from the TL-UNITDATA request primitive, This may occur in some cases 
when the FCS is used, see note 2. It may also occur occasionally even if the FCS is not used. 

NOTE 2: The size shown is the upper limit of the FCS field (when used); a part or all of the FCS could be in the 
previous AL-X-UDATA PDU. 



The LLC header of AL-X-UFINAL is one bit longer than the LLC header of AL-X-UDATA. Therefore there are 
occasional cases when the last part of the TL-SDU (and FCS when used) just fits within an AL-X-UDATA PDU but 
would not fit within an AL-X-UFINAL PDU. In these cases, the sending entity should send the last part of the TL-SDU 
(and FCS when used) within an AL-X-UDATA PDU and then send an empty AL-X-UFINAL PDU (i.e. containing no 
information after the FCS flag) to complete the TL-SDU transmission. 

21 .2.4 Layer 2 signalling PDU definitions 

The layer 2 signalling PDUs carry various types of general signalling information relating to layer 2 functions - either 
LLC or MAC functions. 

NOTE: For convenience, the layer 2 signalling PDUs are treated as LLC PDUs in the PDU structures. Where a 
layer 2 signalling PDU relates to a MAC function: 

■ in the case of transmission, information to be included in the layer 2 signalling PDU is passed 
locally from the MAC to the LLC using the TLE-UNITDATA request primitive; 

■ in the case of reception, information that has been received in the layer 2 signalling PDU is passed 
locally from the LLC to the MAC using the TLE-UNITDATA indication primitive. 
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The following layer 2 signalling PDUs are defined: 
L2-DATA-PRIORITY; 
L2-SCHEDULE-SYNC; 
L2-LINK-FEEDBACK-CONTROL; 
L2-LINK-FEEDBACK-INFO; 
L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITY. 



21.2.4.1 



L2-DATA-PRI0RITY 



• PDU: 

• response to: 

• response expected: 

• short description: 



L2-DATA-PRI0RITY; 



none; 



this PDU is used for the MS to indicate its current short-term data priority 
requirements to the BS. 



The elements of L2-DATA-PRIORITY PDU shall be as defined in table 21.28. 

Table 21.28: L2-DATA-PRI0RITY PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Layer 2 signalling PDU 


Layer 2 signalling PDU subtype 


4 


M 


see table 21.2 


L2-DATA-PRI0RITY 


Number of data priority blocks 


3 


M 


OOO2 


No data priority blocks 


001 2 


One data priority block 


etc. 


etc. 


III2 


7 data priority blocks 


Data priority block 


7 


C 




See notes 1 and 2 


Residual data priority 
(see note 3) 


3 


M 


OOO2 


Priority (lowest) 


etc. 


etc. 


III2 


Priority 7 (highest) 


NOTE 1 : This element shall be present as many times as indicated by the "number of data priority blocks" element. If 

the "number of data priority blocks" element has value OOO2, the data priority block element is not present. 
NOTE 2: The data priority blocks shall be included in decreasing order of data priority (i.e. highest data priority first). 
NOTE 3: This is the data priority for slots following those enumerated in the data priority blocks. 



The data priority block shall be as defined in table 21.29. 
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Table 21.29: Data priority blocl< information element contents in L2-DATA-PRI0RITY PDU 



Information element 


Length 


Type 


Value 


Remark 


Temporary data priority 


3 


M 


OOO2 


Priority (lowest) 


etc. 


etc. 


III2 


Priority 7 (highest) 


Number of slots (see note) 


4 


M 


OOOO2 


1 subslot required 


0001 2 


1 slot required 


001 O2 


2 slots required 


0011 2 


3 slots required 


01002 


4 slots required 


01012 


5 slots required 


01102 


6 slots required 


01112 


8 slots required 


10002 


10 slots required 


1001 2 


13 slots required 


10102 


17 slots required 


10112 


24 slots required 


11002 


34 slots required 


11012 


51 slots required 


11102 


68 slots required 


11112 


Reserved 


NOTE: This element indicates the number of slots required with the specified temporary data priority. 



21.2.4.2 



L2-SCHEDULE-SYNC 



• PDU: 

• response to: 

• response expected: 

• short description: 



L2-SCHEDULE-SYNC; 



none; 



this PDU is used for the BS to give schedule synchronization to the MS 
for the specified NSAPI. 



The elements of L2-SCHEDULE-SYNC PDU shall be as defined in table 21.30. 
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Table 21.30: L2-SCHEDULE-SYNC PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Layer 2 signalling PDU 


Layer 2 signalling PDU subtype 


4 


M 


see table 21.2 


L2-SCHEDULE-SYNC 


NSAPI 


4 


M 


OOOO2 


Reserved 


OOOI2 


NSAPI 1 


etc. 


etc. 


IIIO2 


NSAPI 14 


IIII2 


Reserved 


Timeslot number (see note) 


2 


M 


OO2 


Timeslot 1 


OI2 


Timeslot 2 


IO2 


Timeslot 3 


II2 


Timeslot 4 


Frame number (see note) 


5 


M 


OOOOO2 


Reserved 


00001 2 


Frame 1 


etc. 


etc. 


IOOIO2 


Frame 18 


Others 


Reserved 


Multiframe number (see note) 


6 


M 


OOOOOO2 


Reserved 


000001 2 


IVIultiframe 1 


etc. 


etc. 


IIIIOO2 


Multiframe 60 


Others 


Reserved 


NOTE: The timeslot number, fra 
point for the specified NS 


me number 
5API. 


and multiframe number together comprise the schedule synchronization 



21.2.4.3 



L2-LINK-FEEDBACK-C0NTR0L 



PDU: 

response to: 
response expected: 
short description: 



L2-LINK-FEEDBACK-CONTROL; 



L2-LINK-FEEDBACK-INFO / - 



this PDU is used for the control of Hnk adaptation feedback on a D8PSK 
or QAM channel; in the present document it is sent only by the BS. 



The elements of L2-LINK-FEEDBACK-CONTROL PDU shall be as defined in table 21.31. 
Table 21.31: L2-LINK-FEEDBACK-C0NTR0L PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Layer 2 signalling PDU 


Layer 2 signalling PDU subtype 


4 


M 


see table 21 .2 


L2-LINK-FEEDBACK-C0NTR0L 


Link feedback control type 


3 


M 


OOO2 


Feedback request 


001 2 


Feedback termination 


01 O2 


Reserved 


etc. 


etc. 


III2 


Reserved 


Feedback request 
(see note 1) 


variable 


C 




See table 21.32 


Feedback termination 
(see note 2) 


variable 


C 




See table 21.33 


NOTE 1 : This element shall be present only in the case of a feedback request I.e. link feedback control type element 

set to OOO2. 
NOTE 2: This element shall be present only in the case of a feedback termination i.e. link feedback control type 

element set to 001 2. 
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The feedback request information element shall be as defined in table 21.32. 

Table 21.32: Feedback request information element contents 



Information element 


Length 


Type 


Value 


Remark 


Channel metric type 
(see note 1) 


3 


M 


OOO2 


Bit rate feedback 


001 2 


Eg/No feedback 


01 O2 


Reserved 


etc. 


etc. 


III2 


Reserved 


Feedback duration T.230 
(see note 2) 


6 


M 


OOOOOO2 


No unsolicited feedback messages permitted 


000001 2 


2 multiframes 


00001 O2 


4 multiframes 


etc. 


etc. 


IIIIII2 


126 multiframes 


IVIinimum feedbacl< interval T.231 
(see note 3) 


3 


C 


OOO2 


6 TDIVIA frames 


001 2 


9 TD MA frames 


01 O2 


1 2 TDMA frames 


OII2 


1 8 TD MA frames 


IOO2 


27 TDMA frames 


IOI2 


36 TDMA frames 


IIO2 


54 TDMA frames 


III2 


Predefined (see note 4) 


Data class linkage 
(see note 5) 


3 


C 


OOO2 


Background class 


001 2 


Telemetry class 


01 O2 


Real-time class 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 


NOTE 1 : This element indicates the preferred type of channel performance metric to which the feedback request 

applies. 
NOTE 2: This element indicates whether unsolicited feedback messages may be sent after the immediate response to 

this feedback request; if the element is not set to OOOOOO2, it indicates the maximum time for which 

unsolicited feedback messages may be sent relating to this feedback request. 
NOTE 3: This element shall be present only if unsolicited feedback messages are permitted i.e. feedback duration 

element not set to OOOOOO2. It indicates the minimum permitted time since the last feedback message for 

unsolicited feedback messages. 
NOTE 4: This value indicates that the IVIS shall use a predefined value for timer T.231 ; see annex B. 
NOTE 5: This element shall be present only in the case of a feedback request relating to bit rate feedback i.e. channel 

metric type element set to OOO2. It indicates the specific data class to which the feedback request applies. 
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The feedback termination information element shall be as defined in table 21.33. 

Table 21.33: Feedback termination information element contents 



Information element 


Length 


Type 


Value 


Remark 


Channel metric type 
(see note 1) 


3 


M 


OOO2 


Bit rate feedback 


001 2 


Eg/No feedback 


01 O2 


Reserved 


etc. 


etc. 


III2 


Reserved 


Data class linkage 
(see note 2) 


3 


C 


OOO2 


Background class 


001 2 


Telemetry class 


01 O2 


Real-time class 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 


NOTE 1 : This element indicates the type of channel performance metric to which the feedback termination applies. 
NOTE 2: This element shall be present only in the case of a feedback termination relating to bit rate feedback 

i.e. channel metric type element set to OOO2. It indicates the specific data class to which the feedback 

termination applies. 



21.2.4.4 



L2-LINK-FEEDBACK-INF0 



• PDU: 

• response to: 

• response expected: 

• short description: 



L2-LINK-FEEDBACK-INFO; 
L2-LINK-FEEDBACK-CONTROL / -; 



this PDU is used for the BS or MS to send link adaptation feedback 
information on a D8PSK or QAM channel. 



The elements of L2-LINK-FEEDBACK-INFO PDU shall be as defined in table 21.34. 

Table 21.34: L2-LINK-FEEDBACK-INF0 PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Layer 2 signalling PDU 


Layer 2 signalling PDU subtype 


4 


M 


see table 21 .2 


L2-LINK-FEEDBACK-INF0 


Channel metric type 


3 


M 


OOO2 


Bit rate feedback 


001 2 


Eg/No feedback 


01 O2 


Reserved (see note 1 ) 


etc. 


etc. 


III2 


Reserved (see note 1 ) 


Bit rate feedback information 
(see note 2) 


10 


C 




See "bit rate feedback information" 
information element definition 


Eg/No feedback information 
(see note 3) 


10 


C 




See "Eg/No feedback information" 
information element definition 


NOTE 1 : The lengths of the feedback information for the reserved values of the channel metric type element in this 
PDU are not defined in the present document. If any reserved values of the channel metric type are used in 
future editions of the present document, the length of that feedback information in this PDU may be 10 bits, or 
it may be longer (or shorter) - whereas the length of each type of feedback information that can be sent 
within the AL-X-ACK or AL-X-RNR PDU is restricted to a fixed length of 10 bits (see clause 21.2.3.1a). 

NOTE 2: This element shall be present only in the case of bit rate feedback i.e. channel metric type element set 

to OOO2. 

NOTE 3: This element shall be present only in the case of Eg/No feedback i.e. channel metric type element set to 001 2. 
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21.2.4.5 



L2-LINK-FEEDBACK-INF0-AND-RESIDUAL-DATA-PRI0RITY 



• PDU: 

• response to: 

• response expected: 

• short description: 



L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITY; 
L2-LINK-FEEDBACK-CONTROL / -; 



this PDU is used for the MS to send link adaptation feedback information 
and residual data priority on a D8PSK or QAM channel. 



The elements of L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITY PDU shall be as defined in 

table 21.35. 

Table 21.35: L2-LINK-FEEDBACK-INF0-AND-RESIDUAL-DATA-PRI0RITY PDU contents 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 21.1 


Layer 2 signalling PDU 


Layer 2 signalling PDU subtype 


4 


M 


see table 21 .2 


L2-LINK-FEEDBACK-INF0-AND- 
RESIDUAL-DATA-PRIORITY 


Residual data priority 


3 


M 


OOO2 


Priority (lowest) 


etc. 


etc. 


III2 


Priority 7 (highest) 


Channel metric type 


3 


M 


OOO2 


Bit rate feedback 


001 2 


Eg/No feedback 


01 O2 


Reserved (see note 1 ) 


etc. 


etc. 


III2 


Reserved (see note 1 ) 


Bit rate feedback information 
(see note 2) 


10 


C 




See "bit rate feedback information" 
information element definition 


Eg/No feedback information 
(see note 3) 


10 


C 




See "Eg/No feedback information" 
information element definition 


NOTE 1 : The lengths of the feedback information for the reserved values of the channel metric type element in this 
PDU are not defined in the present document. If any reserved values of the channel metric type are used in 
future editions of the present document, the length of that feedback information in this PDU may be 10 bits, or 
it may be longer (or shorter) - whereas the length of each type of feedback information that can be sent 
within the AL-X-ACK or AL-X-RNR PDU is restricted to a fixed length of 10 bits (see clause 21.2.3.1a). 

NOTE 2: This element shall be present only in the case of bit rate feedback i.e. channel metric type element set 

to OOO2. 

NOTE 3: This element shall be present only in the case of Ej/Nq feedback i.e. channel metric type element set to 001 2. 



21.3 LLC elements 

21.3.1 FCS 

This element is 32 bits long. 

These bits shall be placed in decreasing order for the power of x. The co-efficient of x^^ shall be mapped onto the most 
significant bit. The co-efficient of x*' shall be mapped onto the least significant bit. The FCS calculation is defined in 
clause 22. 

21.3.2 TL-SDUsize 

In the various LLC PDUs, one element often appears generally at the end of the PDU: start of TL-SDU. This indicates 
the beginning of the layer 3 information content which does not have a fixed length. Sometimes, this element is 
optional, which means that PDUs shall be exchanged even without layer 3 specific information. This is generally the 
case for responses, where the acknowledgement PDU is generated by the LLC and may be sent independently from the 
layer 3 message. 
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On the other hand, the segments in an advanced Hnk shall be calculated so that: 

• when using 7i/4-DQPSK or 7r/8-D8PSK modulation, they fit in the MAC offered capacity; or 

• when using QAM modulation: 

in the case of a 25 kHz or 50 kHz channel, the segment size (except possibly for the first and last 
segment of a TL-SDU) is determined by the available space in a 4-QAM rate = 1/2 full-slot MAC block 
at the current bandwidth; 

in the case of a 100 kHz or 150 kHz channel, the segment size (except possibly for the first and last 
segment of a TL-SDU) is determined by the available space in half of a 4-QAM rate = 1/2 full-slot MAC 
block at the current bandwidth. 

21 .3.3 Bit rate feedback information 

The "bit rate feedback information" information element shall be as defined in table 21.36. 

Table 21.36: "Bit rate feedback information" information element contents 



Information element 


Length 


Type 


Value 


Remark 


Preferred bit rate 


5 


M 


OOOOO2 


4-QAM rate = 1/2 orTT/4-DOPSK (see note 1) 


00001 2 


16-QAM rate = 1/2 orTr/S-DBPSK (see note 1) 


0001 O2 


1 6-QAM rate = 1 


00011 2 


64-QAMrate= 1/2 


001 OO2 


64-QAM rate = 2/3 


001012 


64-QAM rate = 1 


001 IO2 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 


Data class linkage 
(see note 2) 


3 


M 


OOO2 


Background class 


001 2 


Telemetry class 


01 O2 


Real-time class 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 


Reserved 


2 


M 


OO2 


Default value 


OI2 


Not used in the present document 


IO2 


Not used in the present document 


II2 


Not used in the present document 


NOTE 1 : QAM bit rates apply only on a 0AM channel; 

D8PSK channel. 
NOTE 2: The data class linkage element indicates the 


71/4-DQPSK and 71/8-D8PSK bit rates apply only on a 
data class to which the preferred bit rate applies. 
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21 .3.4 Es/No feedback information 

The "Ej/Nq feedback information" information element shall be as defined in table 21.37. 

Table 21.37: "Eg/No feedback information" information element contents 



Information element 


Length 


Type 


Value 


Remark 


Eg/No estimate 


4 


M 


OOOO2 


Not specified 


OOOI2 


OdB 


001 O2 


3dB 


OOII2 


6dB 


OIOO2 


9dB 


OIOI2 


12dB 


011 O2 


15dB 


01112 


18dB 


10002 


21 dB 


10012 


24 dB 


10102 


27 dB 


10112 


30 dB 


11002 


33 dB 


11012 


Reserved 


11102 


Reserved 


11112 


Reserved 


Channel model estimate 


2 


M 


002 


Not specified 


012 


Low dispersion (< 2,5 ^is RIVIS) 


102 


High dispersion {> 2,5 |is RIVIS) 


112 


Reserved 


Speed estimate 


4 


M 


00002 


Not specified 


00012 


Low speed (< 10 Hz Doppler spread) 


001 O2 


High speed {> 10 Hz Doppler spread) 


00112 


Reserved 


etc. 


etc. 


IIII2 


Reserved 



21 .4 MAC PDU description 



The following clauses 21.4.1 to 21.4.8.2 describe the information content of the MAC PDUs. 

The information contained in the following PDU descriptions shall be read from left to right, starting at the top and 
going down. The information content shall start with the most significant bit and shall continue until it reaches the least 
significant bit. 

A MAC PDU is composed of a MAC header and a TM-SDU which is passed to the MAC from the LLC layer. The 
MAC header contains information about the content of the PDU. One MAC block (either a half or full timeslot) may 
contain several independent MAC PDUs, each with their own MAC header. The TM-SDU is transported by the MAC, 
but the MAC shall not have any visibility or knowledge of the SDU content. 
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21.4.1 MAC PDU types 



These MAC PDU types as shown in table 21.38 shall be used for C-plane signalling messages, C-plane broadcast 
messages and end-to-end U-plane signalling. 

Table 21.38: MAC PDU types for SCH/F, SCH/HD, STCH, SCH-P8/F, SCH-P8/HD, 

SCH-Q/D and SCH-Q/U 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


OO2 


TMA-SAP: MAC-DATA (uplink) 
or MAC-RESOURCE (downlink) 


OI2 


TMA-SAP: MAC-END or MAC-FRAG 


IO2 


TMB-SAP: Broadcast 


II2 


TMA-SAP: Supplementary MAC PDU (see note) 
TMD-SAP: MAC-U-SIGNAL (U-plane signalling) 


NOTE: The supplementary MAC PDUs shall not be sent on STCH, SCH/HD or SCH-P8/HD. 
The MAC-U-SIGNAL PDU shall only be sent on STCH. 



A PDU subtype bit distinguishes between the supplementary MAC PDUs as shown in table 21.39. 

Table 21.39: Supplementary MAC PDU subtype 



Information element 


Length 


Type 


Value 


Remark 


Supplementary MAC PDU 
subtype 


1 


M 





TMA-SAP: MAC-U-BLCK (uplink) 
or MAC-D-BLCK (downlink) 


1 


Reserved 



The MAC PDU types shown in table 21.38 may be used for the transmission of signalling information in full slots on 
the uplink and downlink and in half slots on the downlink. Under normal operation, the MS shall use MAC-DATA or 
MAC-U-BLCK for transmission on the uplink and the BS shall use MAC-RESOURCE or MAC-D-BLCK for 
transmission on the downlink. MAC-FRAG and MAC -END shall be used on the uplink and downlink for transmission 
of continuations and end of a fragmented SDU. Three types of broadcast PDU are defined, namely SYNC, SYSINFO or 
SYSINFO-Q and ACCESS-DEFINE. These PDUs shall be used by the BS to transmit broadcast information on the 
downlink. MAC-U-SIGNAL shall be used by both MS and BS for the transmission of U-plane signalling information. 

Table 21.40: MAC PDU types for SCH/HU, SCH-P8/HU, SCH-Q/RA and SCH-Q/HU 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type in subslot 


1 


M 





TMA-SAP: MAC-ACCESS 


1 


TMA-SAP: MAC-END-HU 



The MAC PDU types shown in table 2L40 may be used for the transmission of signalling information in half slots 
(i.e. subslots) on the uplink. The MS may transmit signalling information in an uplink subslot using the MAC-ACCESS 
PDU. The MS may also use the MAC-END-HU PDU for transmission of the end of a fragmented SDU. 

The following clauses describe the contents of each of these uplink, downlink and broadcast PDUs. 
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21 .4.2 TMA-SAP: MAC PDU structure for the uplink 

The following clauses describe the MAC PDUs which may be sent on the uplink and which contain C-plane signalling 
information from the TMA-SAP in the MS. 



21.4.2.1 



MAC-ACCESS 



This PDU may be used to send C-plane signalling data on the uplink in a subslot (SCH/HU, SCH-P8/HU, SCH-Q/RA 
or SCH-Q/HU). It shall be used for random access (SCH/HU or SCH-Q/RA) and may also be used for reserved access 
in a subslot (SCH/HU, SCH-P8/HU or SCH-Q/HU). Its contents shall be as shown in table 21.41. 

Table 21.41 : MAC-ACCESS PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type in subslot 


1 


M 





MAC-ACCESS 


Fill bit indication 


1 


M 





No fill bits present 


1 


Fill bit(s) present 


Encrypted flag 


1 


M 





Not encrypted 


1 


Encrypted 


Address type 


2 


M 


002 


SSI 


012 


Event Label (address length 10, see note 1) 


102 


USSI (migrating MS un-exchanged address) 


112 


SMI (management address) 


Address 


24/10 


M 




SSI, USSI, SMI or Event Label according to address type 


Optional field flag 


1 


M 





No length indication nor capacity request 


1 


Length indication or capacity request 


Length indication or 
capacity request 


1 


C 





Length indication 


1 


Capacity request (i.e. fragmentation flag + reservation 
requirement) 


Length indication 


5 


C 


000002 


Null PDU 


00001 2 


Length of MAC PDU = value x Y^ octets (see note 2) 


etc. 


etc. 


OIIIO2 


Length of MAC PDU = value x Yi octets 


OIIII2 


Length of MAC PDU = (14 x Yi + (value - 14) x Z^ octets 


etc. 


etc. 


IIIOO2 


Length of MAC PDU = (14 x Yi + (value - 14) x Z^ octets 


IIIOI2 


Reserved 


IIIIO2 


Reserved 


IIIII2 


Length of MAC PDU (see note 3) = 
1 81 bits when PDU sent on a 25 kHz 0AM channel 
389 bits when PDU sent on a 50 kHz 0AM channel 
402 bits when PDU sent on a 100 kHz QAM channel 
610 bits when PDU sent on a 150 kHz QAM channel 
else Reserved 


Fragmentation flag 


1 


C 





TM-SDU not fragmented 


1 


Start of fragmentation 


Reservation requirement 


4 


C 




See reservation requirement information element definition 


TM-SDU 


varies 


C 






NOTE 1 : The address length of the other address types is 24. 

NOTE 2: For values of length indication up to 01 1 1O2, the unit of the length indication is Yi octets whereas, for higher 

values, the incremental unit of the length indication is Z^ octets. The values of Yi and Zi depend on the 

bandwidth, modulation and coding rate with which the PDU is sent; the values of Yi and Zi are given in 

clause 21 .6 for each combination. 
NOTE 3: The length of MAC PDU indicated by length indication 1 1 1 1 12 is set to correspond to the normal size of an 

advanced link data segment on a QAM channel. 
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The first bit of the MAC header distinguishes between the two possible PDU types which can be sent in a subslot. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block or less than the size of the TM-SDU indicated by the length 
indication field. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header length. 

The encrypted flag shall indicate whether or not the TM-SDU contents are encrypted. The MAC header shall not be 
encrypted except that the address is encrypted when appropriate if the encrypted flag is set to 1 (for details of the 
address encryption method and when it is used, see EN 300 392-7 [8]). In the case of fragmentation, the setting of the 
encrypted flag in the MAC-ACCESS PDU shall apply to all fragments of that TM-SDU. 

The address type field shall indicate the type of address contained in the address field. The length of the address field 
shall be 10 bits for an event label or 24 bits for SSI, USSI or SMI. 

The optional field flag shall indicate whether any of the optional fields are present in the PDU header. If optional fields 
are present the next bit (length indication or capacity request) shall indicate whether the PDU header contains a length 
indication field or a capacity request field. If length indication is indicated, then the next field shall be length indication. 
Length indication shall refer to the length of the MAC PDU (which comprises the MAC PDU header and the TM-SDU) 
and should be used only if association within the uplink subslot is required or for transmission of the null PDU. 

The units used for the length indication depend on the bandwidth, modulation and coding rate with which the PDU is 
sent; see clause 21.6. The defined values of the length indication cover up to the size of the MAC block or the 
maximum size of a MAC-ACCESS PDU (2 668 bits), whichever is the lesser. 

The header length of a MAC-ACCESS PDU depends on the type of address in use and whether or not there is a length 
indication or capacity request. The header length is shown in table 21 .42 for each of the possible combinations. Then 
the maximum TM-SDU length is shown in table 21.43 for each of the possible header lengths and logical channels. 

Table 21.42: Length of MAC-ACCESS PDU header 



Content of Header Fields 


Header Length 
[bits] 


Address = Event Label 

No length indication nor capacity request 


16 


Address = SSI, USSI or SMI 

No length indication nor capacity request 


30 


Address = Event Label 

Length indication or capacity request 


22 


Address = SSI, USSI or SMI 
Length indication or capacity request 


36 



The length indication field may be used to indicate a null PDU. If a null PDU is indicated, there shall be no further 
information in the PDU after the length indication field. The length of the null PDU, therefore, shall be 22 bits if an 
event label is used as an address or 36 bits if an SSI, USSI or SMI is used as an address. The null PDU, if it appears in a 
MAC block, shall always be the last PDU in that block. Any spare capacity after the null PDU shall be filled with fill 

bits. 

If capacity request is indicated in the length indication or capacity request bit, the next field shall be fragmentation flag 
followed by reservation requirement. Capacity request shall be used when the MS has further signalling to send, which 
may or may not be subsequent fragments of a fragmented SDU (as indicated by the fragmentation flag). The PDU may 
only contain either the length indication field or the capacity request field (comprising fragmentation flag and 
reservation requirement), but not both. 

NOTE 1: An MS generally sets the "Optional field flag" to "1" only for transmission of the Null PDU or if PDU 
association is required within the subslot or if the MS has further signalling messages ready to be sent. 
Otherwise the flag is set to "0". For example, when the MAC-ACCESS PDU is sent on SCH/HU 
(i.e. using 7i/4-DQPSK), this gives a maximum TM-SDU length of 62 bits (or 76 bits if an event label is 
used). 

NOTE 2: The "Optional field flag" is provided in the PDU in order to economize on the use of bits for the most 
usual cases. It is not provided in the MAC-END-HU, MAC-DATA or MAC-END PDUs, in which the 
size constraint is less critical. 
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NOTE 3: For example, the defined structure of the MAC-ACCESS PDU allows the CMCE U-SETUP PDU to be 
sent within a 3i/4-DQPSK subslot (i.e. using SCH/HU), provided that: 

(a) the full TSI of the called party is not needed in the U-SETUP PDU; and 

(b) the PCS is not added by the LLC; and 

(c) the MAC does not include a capacity request so that the optional field flag = "0" 
(or an event label is used for addressing). 

Table 21.43: Maximum length of TM-SDU in MAC-ACCESS PDU 



Logical channel 


Maximum TM-SDU length [bits] | 


Event label. 

No length 

indication nor 

capacity request 


SSI, USSI or SMI. 

No length 

indication nor 

capacity request 


Event label. 

Length indication 

or capacity request 


SSI, USSI or SMI. 

Length indication 

or capacity request 


SCH/HU 


76 


62 


70 


56 


SCH-P8/HU 


132 


118 


126 


112 


SCH-Q/RA 


49 


35 


43 


29 


SCH-Q/HU25-4H 


41 


27 


35 


21 


SCH-Q/HU25-16H 


117 


103 


111 


97 


SCH-Q/HU25-16U 


272 


258 


266 


252 


SCH-Q/HU25-64H 


193 


179 


187 


173 


SCH-Q/HU25-64M 


269 


255 


263 


249 


SCH-Q/HU25-64U 


424 


410 


418 


404 


SCH-Q/HU50-4H 


125 


111 


119 


105 


SCH-Q/HU50-16H 


285 


271 


279 


265 


SCH-Q/HU50-16U 


608 


594 


602 


588 


SCH-Q/HU50-64H 


445 


431 


439 


425 


SCH-Q/HU50-64M 


605 


591 


599 


585 


SCH-Q/HU50-64U 


928 


914 


922 


908 


SCH-Q/HU100-4H 


293 


279 


287 


273 


SCH-Q/HU100-16H 


621 


607 


615 


601 


SCH-Q/HU100-16U 


1 280 


1 266 


1 274 


1 260 


SCH-Q/HU100-64H 


949 


935 


943 


929 


SCH-Q/HU100-64M 


1 277 


1 263 


1 271 


1 257 


SCH-Q/HU100-64U 


1 936 


1 922 


1 930 


1 916 


SCH-Q/HU150-4H 


461 


447 


455 


441 


SCH-Q/HU150-16H 


957 


943 


951 


937 


SCH-Q/HU150-16U 


1 952 


1 938 


1 946 


1 932 


SCH-Q/HU150-64H 


1 453 


1 439 


1 447 


1 433 


SCH-Q/HU150-64M 


1 949 


1 935 


1 943 


1 929 


SCH-Q/HU150-64U 


2 632 (see note) 


2 632 (see note) 


2 632 (see note) 


2 632 (see note) 


NOTE: The maximum length of TM-SDU in this IVIAC blocl< is constrained by the maximum permitted size of 
TIVI-SDU (N.202) rather than by the size of the IVIAC block. 
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21.4.2.2 



MAC-END-HU 



This PDU shall be used to send the last fragment of fragmented C-plane signalling data on the uplink using a reserved 
subslot (SCH/HU, SCH-P8/HU or SCH-Q/HU). Its contents shall be as shown in table 21.44. 

Table 21.44: MAC-END-HU PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type in subslot 


1 


M 


1 


MAC-END-HU 


Fill bit indication 


1 


M 





No fill bits present 


1 


Fill bit(s) present 


Length indication or 
capacity request 


1 


M 





Length indication 


1 


Reservation requirement (i.e. Capacity request) 


Length indication 


4 


C 


00002 


Reserved 


0001 2 


Length of MAC PDU = value x Zi octets (see note) 


etc. 


etc. 


IIII2 


Length of MAC PDU = value x Z^ octets 


Reservation requirement 


4 


C 




See reservation requirement information element 
definition 


TM-SDU 


varies 


c 






NOTE: The unit of the length indication is Z^ octets. The value of Zi depends on the bandwidth, modulation and 
coding rate with which the PDU is sent; the value of Z^ is given in clause 21 .6 for each combination. 



The first bit of the MAC header distinguishes between the two possible PDU types which can be sent in a subslot. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block or less than the size of the TM-SDU indicated by the length 
indication field. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header length. 

The length indication or capacity request field shall indicate whether the PDU header contains a length indication field 
or a capacity request field. If length indication is indicated, then the next field shall be length indication. Length 
indication shall refer to the length of the MAC PDU which comprises the MAC PDU header and the TM-SDU. The 
length indicator shall be used if association within the uplink subslot is required or if the MS has no further signalling to 
send. If reservation requirement is indicated, the next field shall be reservation requirement which shall be used when 
the MS has further C-plane signalling messages ready to send. In that case the length of the TM-SDU is defined by the 
fill bit mechanism. The PDU may only contain either the length indication field or the reservation requirement field. 

The units used for the length indication depend on the bandwidth, modulation and coding rate with which the PDU is 
sent; see clause 21.6. The defined values of the length indication cover up to the size of the MAC block or the 
maximum size of a MAC-END-HU PDU (2 638 bits), whichever is the lesser. 

The header length of a MAC-END-HU PDU shall be equal to 7 bits. The maximum TM-SDU length is shown in 

table 21.45. 
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Table 21.45: Maximum length of TM-SDU in MAC-END-HU PDU 



Logical channel 


Maximum TM-SDU length [bits] 


SCH/HU 


85 


SCH-P8/HU 


141 


SCH-Q/HU25-4H 


50 


SCH-Q/HU25-16H 


126 


SCH-Q/HU25-16U 


281 


SCH-Q/HU25-64H 


202 


SCH-Q/HU25-64M 


278 


SCH-Q/HU25-64U 


433 


SCH-Q/HU50-4H 


134 


SCH-Q/HU50-16H 


294 


SCH-Q/HU50-16U 


617 


SCH-Q/HU50-64H 


454 


SCH-Q/HU50-64M 


614 


SCH-Q/HU50-64U 


937 


SCH-Q/HU100-4H 


302 


SCH-Q/HU100-16H 


630 


SCH-Q/HU100-16U 


1 289 


SCH-Q/HU100-64H 


958 


SCH-Q/HU100-64M 


1 286 


SCH-Q/HU100-64U 


1 945 


SCH-Q/HU150-4H 


470 


SCH-Q/HU150-16H 


966 


SCH-Q/HU150-16U 


1 961 


SCH-Q/HU150-64H 


1 462 


SCH-Q/HU150-64M 


1 958 


SCH-Q/HU150-64U 


2 631 (see note) 


NOTE: The maximum length of TM-SDU in this IVIAC blocl< is 
constrained by the maximum permitted size of TM-SDU 
(N.202) rather than by the size of the MAC blocl<. 
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21.4.2.3 MAC-DATA 

This PDU may be used to send C-plane signalling data on the uplink in a full slot (SCH/F, SCH-P8/F or SCH-Q/U). 

It may also be used to send C-plane signalling data in the first half of a full uplink slot using the stealing channel 
(STCH). If the second half of a full uplink slot is also stolen, the MAC -DATA PDU may be used to send another 
C-plane PDU in the second half slot. 

The contents of the MAC-DATA PDU shall be as shown in table 21.46. 

Table 21.46: MAC-DATA PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


OO2 


MAC- DATA 


Fill bit indication 


1 


M 





No fill bit present 


1 


Fill bit(s) present 


Encrypted flag 


1 


M 





Not encrypted 


1 


Encrypted 


Address type 


2 


M 


002 


SSI 


012 


Event Label (address length 10, see note 1) 


102 


USSI (migrating MS un-exchanged address) 


112 


SMI (management address) 


Address 


24/10 


M 




SSI, USSI, SMI or Event Label according to address type 


Length indication or 
capacity request 


1 


M 





Length indication 


1 


Capacity request (i.e. fragmentation flag + reservation 
requirement + reserved bit) 


Length indication 


6 


C 


0000002 


Null PDU 


000001 2 


Reserved 


00001 O2 


Length of MAC PDU = value x Y2 octets (see note 2) 


etc. 


etc. 


OIOOIO2 


Length of MAC PDU = value x Y2 octets 


OIOOII2 


Length of MAC PDU = (18 x Y2 + (value - 18) x Z2) octets 


etc. 


etc. 


IIIOOO2 


Length of MAC PDU = (18 x Y2 + (value - 18) x Z2) octets 


IIIOOI2 


Reserved 


IIIOIO2 


Reserved 


IIIOII2 


Reserved 


IIIIOO2 


Reserved 


IIIIOI2 


Length of MAC PDU (see note 3) = 
181 bits when PDU sent on a 25 kHz QAM channel 
389 bits when PDU sent on a 50 kHz QAM channel 
402 bits when PDU sent on a 1 00 kHz 0AM channel 
610 bits when PDU sent on a 1 50 kHz 0AM channel 
else Reserved 


IIIIIO2 


Second half slot stolen on STCH 


IIIIII2 


Start of fragmentation on STCH 


Fragmentation flag 


1 


C 





TM-SDU not fragmented 


1 


Start of fragmentation 


Reservation requirement 


4 


C 




See reservation requirement information element definition 


Reserved 


1 


C 





Default value 


1 


Not used in the present document 


TM-SDU 


varies 


C 






NOTE 1 : The address length of the other address types is 24. 

NOTE 2: For values of length indication up to 01 001 O2, the unit of the length indication is Y2 octets whereas, for higher 

values, the incremental unit of the length indication is Z2 octets. The values of Y2 and Z2 depend on the 

bandwidth, modulation and coding rate with which the PDU is sent; the values of Y2 and Z2 are given in 

clause 21 .6 for each combination. 
NOTE 3: The length of MAC PDU indicated by length indication 1 1 1 1OI2 is set to correspond to the normal size of an 

advanced link data segment on a QAM channel. 
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The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the upHnk 
SCH/F, SCH-P8/F, SCH-Q/U or STCH. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block or less than the size of the TM-SDU indicated by the length 
indication field. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header length. 

The encrypted flag shall indicate whether or not the TM-SDU contents are encrypted. The MAC header shall not be 
encrypted except that the address is encrypted when appropriate if the encrypted flag is set to 1 (for details of the 
address encryption method and when it is used, see EN 300 392-7 [8]). In the case of fragmentation, the setting of the 
encrypted flag in the MAC-DATA PDU applies to all fragments of the TM-SDU. 

The address type field shall indicate the type of address contained in the address field. The length of the address field 
shall be 10 bits for an event label or 24 bits for SSI, USSI or SMI. 

The length indication or capacity request field shall indicate whether the PDU header contains a length indication field 
or a capacity request field. If length indication is indicated, then the next field shall be length indication. Length 
indication shall refer to the length of the MAC PDU (which comprises the MAC PDU header and the TM-SDU) and 
shall be used if association is required or if the MS has no further signalling to send. If capacity request is indicated, the 
next field shall be fragmentation flag followed by reservation requirement and the reserved bit. Capacity request shall 
be used on SCH/F, SCH-P8/F or SCH-Q/U when the MS has further signalling to send, which may or may not be 
subsequent fragments of a fragmented SDU (as indicated by the fragmentation flag). The PDU may only contain either 
the length indication field or the capacity request field (comprising fragmentation flag, reservation requirement and the 
reserved bit). 

The units used for the length indication depend on the bandwidth, modulation and coding rate with which the PDU is 
sent; see clause 21.6. The defined values of the length indication cover up to the size of the MAC block or the 
maximum size of a MAC -DATA PDU (2 669 bits), whichever is the lesser. 

The header length of a MAC-DATA PDU depends on the type of address in use. It shall be 37 bits when an SSI, USSI 
or SMI is used and 23 bits when an event label is used. The maximum TM-SDU length is shown in table 21.47 for each 
of the header lengths and logical channels. 

The length indication field may be used to indicate a null PDU. If a null PDU is indicated, there shall be no further 
information in the PDU after the length indication field. The length of the null PDU, therefore, shall be 23 bits if an 
event label is used as an address or 37 bits if an SSI, USSI or SMI is used as an address. After a null PDU, there shall be 
no further PDUs in the MAC block and the remaining capacity shall contain fill bits. 

This MAC-DATA PDU shall also be used for C-plane signalling using the STCH on the upUnk. By default, the STCH 
occupies only the first half slot. The second half slot may also be stolen, either for the last fragment of a fragmented 
SDU or for subsequent PDUs which the MAC may have ready to send or for U-plane signalling. A length indication of 
11 11 II2 shall be used to indicate that the second half slot is stolen for the last fragment of a fragmented SDU. A length 
indication of 1 1 1 1 IO2 shall be used to indicate that the second half slot is stolen for subsequent C-plane signalling or 
U-plane signalling. The last fragment shall use the MAC -END PDU, while subsequent C-plane PDUs shall use the 
MAC-DATA PDU and U-plane signalling shall use the MAC-U-SIGNAL PDU. It shall only be possible to fragment 
SDUs over the two halves of a full slot on the STCH. 
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Table 21.47: Maximum length of TM-SDU in MAC-DATA PDU 



Logical channel 


Maximum TM-SDU length [bits] | 


Using event label 


Using SSI, USSI or SMI 


SCH/F 


245 


231 


STCH 


101 


87 


SCH-P8/F 


389 


375 


SCH-Q/U25-4H 


158 


144 


SCH-Q/U25-16H 


358 


344 


SCH-Q/U25-16U 


761 


747 


SCH-Q/U25-64H 


558 


544 


SCH-Q/U25-64M 


758 


744 


SCH-Q/U25-64U 


1 161 


1 147 


SCH-Q/U50-4H 


366 


352 


SCH-Q/U50-16H 


774 


760 


SCH-Q/U50-16U 


1 593 


1 579 


SCH-Q/U50-64H 


1 182 


1 168 


SCH-Q/U50-64M 


1 590 


1 576 


SCH-Q/U50-64U 


2 409 


2 395 


SCH-Q/U100-4H 


782 


768 


SCH-Q/U100-16H 


1 606 


1 592 


SCH-Q/U100-16U 


2 632 (see note) 


2 632 (see note) 


SCH-Q/U100-64H 


2 430 


2416 


SCH-Q/U100-64M 


2 632 (see note) 


2 632 (see note) 


SCH-Q/U100-64U 


2 632 (see note) 


2 632 (see note) 


SCH-Q/U150-4H 


1 198 


1 184 


SCH-Q/U150-16H 


2 438 


2 424 


SCH-Q/U150-16U 


2 632 (see note) 


2 632 (see note) 


SCH-Q/U150-64H 


2 632 (see note) 


2 632 (see note) 


SCH-Q/U150-64M 


2 632 (see note) 


2 632 (see note) 


SCH-Q/U150-64U 


2 632 (see note) 


2 632 (see note) 


NOTE: The maximum length of TM-SDU in this IVIAC blocl< is constrained by the maximum 
permitted size of TIVI-SDU (N.202) rather than by the size of the IVIAC block. 



21.4.2.4 



MAC-FRAG (uplink) 



This PDU shall be used to send continuation fragments of fragmented C-plane signalling data on the uplink using a full 
slot (SCH/F, SCH-P8/F or SCH-Q/U). Its contents shall be as shown in table 21.48. 

Table 21.48: MAC-FRAG (uplinlt) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


Olg 


MAC-FRAG or MAC-END 


MAC PDU subtype 


1 


M 





MAC-FRAG 


Fill bit indication 


1 


M 





No fill bits present 


1 


Fill bit(s) present 


TM-SDU 


varies 


M 







The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the uplink using 
a full slot. A PDU subtype bit distinguishes between MAC-FRAG and MAC-END which share the same MAC PDU 
type. 

The fill bit indication shall indicate if there are any fill bits which shall be added whenever the size of the TM-SDU 
fragment is less than the available capacity of a full slot. Fill bits may be required for this PDU because the MAC-END 
header length is greater than the header length of this PDU. This means that it is possible that the last fragment of an 
SDU may be too large to fit into a MAC -END PDU but too small to fill the maximum TM-SDU space available in the 
MAC-FRAG PDU. In this case, fill bits are required in the MAC -FRAG PDU and MAC-END shall be sent with a 
zero-length TM-SDU. 

The header length of a MAC-FRAG shall be equal to 4 bits. The maximum TM-SDU length is shown in table 21.49. 
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Table 21.49: Maximum length of TM-SDU in uplink MAC-FRAG PDU 



Logical channel 


Maximum TM-SDU length [bits] 


SCH/F 


264 


SCH-P8/F 


408 


SCH-Q/U25-4H 


177 


SCH-Q/U25-16H 


377 


SCH-Q/U25-16U 


780 


SCH-Q/U25-64H 


577 


SCH-Q/U25-64M 


777 


SCH-Q/U25-64U 


1 180 


SCH-Q/U50-4H 


385 


SCH-Q/U50-16H 


793 


SCH-Q/U50-16U 


1 612 


SCH-Q/U50-64H 


1 201 


SCH-Q/U50-64M 


1 609 


SCH-Q/U50-64U 


2 428 


SCH-Q/U100-4H 


801 


SCH-Q/U100-16H 


1 625 


SCH-Q/U100-16U 


Not applicable (see note) 


SCH-Q/U100-64H 


2 449 


SCH-Q/U100-64M 


Not applicable (see note) 


SCH-Q/U100-64U 


Not applicable (see note) 


SCH-Q/U150-4H 


1 217 


SCH-Q/U150-16H 


2 457 


SCH-Q/U150-16U 


Not applicable (see note) 


SCH-Q/U150-64H 


Not applicable (see note) 


SCH-Q/U150-64M 


Not applicable (see note) 


SCH-Q/U150-64U 


Not applicable (see note) 


NOTE: For these logical channels, the MAC block is large enough to contain the 
maximum permitted size of TIVI-SDU so the MS has no need to use 
MAC-FRAG. (It completes the TM-SDU using MAC-END instead.) 



21.4.2.5 MAC-END (uplink) 

This PDU shall be used to send the last fragment of fragmented C-plane signalling data on the uplink using a full slot 
(SCH/F, SCH-P8/F or SCH-Q/U). It shall also be used to send the last fragment of fragmented C-plane signalling in the 
second half of a stolen full slot on the uplink. Its contents shall be as shown in table 21.50. 

Table 21.50: MAC-END (uplink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


OI2 


MAC-FRAG or MAC-END 


MAC PDU subtype 


1 


M 


1 


MAC-END 


Fill bit indication 


1 


M 





No fill bits present 


1 


Fill bit(s) present 


Length indication / 
reservation requirement 


6 


M 


OOOOOO2 


Reserved 


000001 2 


Length of MAC PDU = value x Y2 octets (see note) 


etc. 


etc. 


0001 IO2 


Length of MAC PDU = value x Y2 octets 


0001 II2 


Length of MAC PDU = (6 x Y2 -h (value - 6) x Z2) octets 


etc. 


etc. 


IOIIIO2 


Length of MAC PDU = (6 x Y2 -h (value - 6) x Z2) octets 


IOIIII2 


Reserved 


IIXXXX2 


See reservation requirement information element definition 


TM-SDU 


varies 


C 






NOTE: For values of length indication up to 0001 1 02, the unit of the length indication is Y2 octets whereas, for higher 
values, the incremental unit of the length indication is Z2 octets. The values of Y2 and Z2 depend on the 
bandwidth, modulation and coding rate with which the PDU is sent; the values of Y2 and Z2 are given in 
clause 21 .6 for each combination. 
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The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the uplink 
SCH/F, SCH-P8/F, SCH-Q/U or STCH. A PDU subtype bit distinguishes between MAC-FRAG and MAC-END which 
share the same MAC PDU type. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the PDU is less 
than the available capacity of the MAC block or less than the size of the PDU indicated by the length indication field. 
The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header length. 

The next 6-bit field shall indicate length indication or a reservation requirement. A value from OOOOOI2 to 101 1 IO2 shall 
indicate the length of the PDU. A value beginning with 1 12 shall indicate a reservation requirement which shall be used 
on SCH/F, SCH-P8/F or SCH-Q/U when the MS has further C-plane signalling to send. The reservation requirement 
information is contained in the 4 least significant bits of these values, the meaning of which is given in the reservation 
requirement element definition. 

The units used for the length indication depend on the bandwidth, modulation and coding rate with which the PDU is 
sent; see clause 21.6. The defined values of the length indication cover up to the size of the MAC block or the 
maximum size of a MAC -END PDU (2 641 bits), whichever is the lesser. 

The header length of a MAC-END PDU shall be equal to 10 bits. The maximum TM-SDU length is shown in 

table 21.51. The length indicated in the MAC PDU header shall refer to the MAC PDU which comprises the MAC PDU 

header and the TM-SDU. 

Table 21 .51 : Maximum length of TM-SDU in uplink MAC-END PDU 



Logical channel 


Maximum TM-SDU length [bits] 


SCH/F 


258 


STCH 


114 


SCH-P8/F 


402 


SCH-Q/U25-4H 


171 


SCH-Q/U25-16H 


371 


SCH-Q/U25-16U 


774 


SCH-Q/U25-64H 


571 


SCH-Q/U25-64M 


771 


SCH-Q/U25-64U 


1 174 


SCH-Q/U50-4H 


379 


SCH-Q/U50-16H 


787 


SCH-Q/U50-16U 


1 606 


SCH-Q/U50-64H 


1 195 


SCH-Q/U50-64M 


1 603 


SCH-Q/U50-64U 


2 422 


SCH-Q/U 100-4H 


795 


SCH-Q/U100-16H 


1 619 


SCH-Q/U100-16U 


2 631 (see note) 


SCH-Q/U 100-64H 


2 443 


SCH-Q/U 100-64M 


2 631 (see note) 


SCH-Q/U 100-64U 


2 631 (see note) 


SCH-Q/U 150-4H 


1 211 


SCH-Q/U150-16H 


2 451 


SCH-Q/U150-16U 


2 631 (see note) 


SCH-Q/U 150-64H 


2 631 (see note) 


SCH-Q/U 150-64M 


2 631 (see note) 


SCH-Q/U 150-64U 


2 631 (see note) 


NOTE: The maximum length of TM-SDU in this IVIAC blocl< is 
constrained by the maximum permitted size of TM-SDU 
(N.202) rather than by the size of the MAC blocl<. 



21.4.2.6 



MAC-U-BLCK 



This PDU may optionally be used to send C-plane signalling data on the uplink in a full slot (SCH/F, SCH-P8/F or 
SCH-Q/U) in cases when an event label can be used and a pre-defined length is appropriate e.g. when sending an 
advanced link data segment. It cannot be used if SSI or SMI addressing or fragmentation is needed, or to indicate a null 
PDU; when any of these functions are needed, the MS should use the MAC -DATA PDU. 
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The MAC-U-BLCK PDU has a slightly smaller MAC header than the MAC -DATA PDU so can carry slightly more 
data. If the MS has a valid event label, it may choose to use the MAC-U-BLCK PDU instead of MAC-DATA e.g. when 
sending an advanced link data segment. 

NOTE 1 : The MAC-U-BLCK PDU should not be used when the pre-defined length is not appropriate. For 
example, when the MS is sending a basic link message or a short advanced link message or the last 
segment of an advanced link message, use of the MAC-DATA PDU may be more efficient. 

The MAC-U-BLCK PDU uses the same MAC PDU type as the MAC-U-SIGNAL PDU, which is sent using the 
steaHng channel (STCH). Therefore the MAC-U-BLCK PDU shall not be sent on STCH. 

The contents of the MAC-U-BLCK PDU shall be as shown in table 2L52. 

Table 21.52: MAC-U-BLCK PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


II2 


Supplementary MAC PDU 


Supplementary MAC 
PDU subtype 


1 


M 





MAC-U-BLCK 


Fill bit indication 


1 


M 





No fill bit present 


1 


Fill bit(s) present 


Encrypted flag 


1 


M 





Not encrypted 


1 


Encrypted 


Address 


10 


M 




Event label 


Reservation requirement 


4 


M 




See reservation requirement information element definition 


TM-SDU 


varies 


C 







The length of the MAC-U-BLCK PDU is defined implicitly, as shown in table 21.53. The implicit length shall refer to 
the length of the MAC PDU, which comprises the MAC PDU header and the TM-SDU. For a 3i/4-DQPSK or 
71/8-D8PSK slot, the implicit length matches the size of the MAC block. On a QAM channel, the implicit length of the 
MAC-U-BLCK PDU is set to correspond to the normal size of an advanced link data segment i.e.: 

• in the case of a 25 kHz or 50 kHz channel, the implicit length corresponds to the size of a 4-QAM rate = 1/2 
full-slot MAC block at the current bandwidth; 

• in the case of a 100 kHz or 150 kHz channel, the implicit length corresponds to half the size of a 4-QAM 
rate = 1/2 full-slot MAC block at the current bandwidth. 

Table 21.53: Implicit length of MAC-U-BLCK PDU 



Logical channel 


Implicit length of MAC-U-BLCK PDU 


SCH/F 


268 bits 


SCH-P8/F 


412 bits 


SCH-Q/U25 


181 bits 


SCH-Q/U50 


389 bits 


SCH-Q/U100 


402 bits 


SCH-Q/U150 


610 bits 



The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the uplink 
SCH/F, SCH-P8/F or SCH-Q/U. The supplementary MAC PDU subtype bit distinguishes between supplementary 
PDUs which share the same MAC PDU type. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block or less than the size of the TM-SDU indicated by the implicit length 
of the MAC-U-BLCK PDU. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header 
length. 

The encrypted flag shall indicate whether or not the TM-SDU contents are encrypted. The MAC header shall not be 
encrypted. 

The address field shall contain an event label. 

NOTE 2: As defined in EN 300 392-7 [8], the event label is not encrypted. 



£75/ 



608 



ETSI TS 300 392-2 V3.3.1 (2008-10) 



The reservation requirement field shall indicate the MS's current requirement for reserved slots. This field is mandatory 
in the MAC-U-BLCK PDU. (A specific value is defined in the reservation requirement when sent in MAC-U-BLCK for 
use when the MS has no further signalling to send.) 

The header length of a MAC-U-BLCK PDU shall be equal to 19 bits. The maximum TM-SDU length is shown in 
table 21.54. 

Table 21.54: Maximum length of TM-SDU in MAC-U-BLCK PDU 



Logical channel 


Maximum TM-SDU length [bits] 


SCH/F 


249 


SCH-P8/F 


393 


SCH-Q/U25 


162 


SCH-Q/U50 


370 


SCH-Q/U100 


383 


SCH-Q/U150 


591 



21 .4.3 TMA-SAP: MAC PDU structure for the downlink 

The following clauses describe the MAC PDUs which may be sent on the downlink and which contain C-plane 
signalling information for the TMA-SAP in the MS. 



21.4.3.1 



MAC-RESOURCE 



This PDU may be used to send C-plane signalling data on the downHnk in a full slot (SCH/F, SCH-P8/F or SCH-Q/D) 
or in the first or second half slot of a full slot (SCH/HD or SCH-P8/HD). It may also be used to send C-plane signalling 
data in the first half of a downlink slot using the Stealing Channel (STCH). If the second half of a downlink slot is also 
stolen, the MAC-RESOURCE PDU may be used to send another PDU in the second half slot. 

This PDU may be sent without a TM-SDU in order to allocate uplink capacity, send a channel allocation or control 
mobile transmit power. 

The contents of the MAC-RESOURCE PDU shall be as shown in table 21.55. 
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Table 21.55: MAC-RESOURCE PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


OO2 


MAC-RESOURCE 


Fill bit indication 


1 


M 





No fill bits present 


1 


Fill bit(s) present 


Position of grant 


1 


M 





Slot grant (if any) is on current channel 


1 


Slot grant (if any) is on allocated channel 


Encryption mode 


2 


M 


002 


Not encrypted 


012 


See EN 300 392-7 [8] 


102 


See EN 300 392-7 [8] 


112 


See EN 300 392-7 [8] 


Random access flag 


1 


M 





Undefined 


1 


Random Access Acknowledged 


Length indication 


6 


M 


0000002 


Reserved 


000001 2 


Length of MAC PDU = value x Y2 octets (see note 1) 


etc. 


etc. 


OIOOIO2 


Length of MAC PDU = value x Y2 octets 


OIOOII2 


Length of MAC PDU = (18 x Y2 + (value - 18) x Z2) octets 


etc. 


etc. 


IIIOIO2 


Length of MAC PDU = (18 x Y2 + (value - 18) x Z2) octets 


IIIOII2 


Reserved 


1 1 1 1 OO2 


Reserved 


IIIIOI2 


Length of MAC PDU (see note 2) = 
185 bits when PDU sent on a 25 kHz QAM channel 
421 bits when PDU sent on a 50 kHz QAM channel 
446 bits when PDU sent on a 1 00 kHz QAM channel 
682 bits when PDU sent on a 1 50 kHz QAM channel 
else Reserved 


IIIIIO2 


Second half slot stolen in STCH 


IIIIII2 


Start of fragmentation 


Address type 


3 


M 


OOO2 


Null PDU 


001 2 


SSI 


01 O2 


Event Label 


OII2 


USSI (migrating MS un-exchanged address) 


IOO2 


SMI (management address) 


IOI2 


SSI -1- Event Label (event label assignment) 


IIO2 


SSI -1- Usage Marker (usage marker assignment) 


III2 


SMI + Event Label (event label assignment) 


Address 


34/ 
30/ 
24/ 
10 


M 




SSI/SMI -1- Event Label 
SSI -1- Usage Marker 
SSI, USSI or SMI 
Event Label 


Immediate napping 
permission flag (see note 3) 


1 


C 





Immediate napping permission not given 


1 


Immediate napping permission given 


Power control flag 


1 


M 





No power control information element in PDU 


1 


Power control information element in PDU 


Power control element 


4 


C 




See power control information element definition 


Slot granting flag 


1 


M 





No slot granting information elements in PDU 


1 


Slot granting information element in PDU 


Multiple slot granting flag 
(see note 4) 


1 


C 





Basic slot granting information element in PDU 


1 


Multiple slot granting information element in PDU 


Basic slot granting element 
(see note 5) 


8 


C 




See basic slot granting information element definition 


Multiple slot granting 
element (see note 6) 


variable 


c 




See multiple slot granting information element definition 
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Information element 


Length 


Type 


Value 


Remark 


Channel allocation flag 


1 


M 





No channel allocation information element in PDU 


1 


Channel allocation information element in PDU 


Channel allocation element 


variable 


C 




See channel allocation information element definition 


TM-SDU 


variable 


C 






NOTE 1 : For values of length indication up to 01 001 O2, the unit of the length indication is Y2 octets whereas, for higher 

values, the incremental unit of the length indication is Zg octets. The values of Y2 and Z2 depend on the 

bandwidth, modulation and coding rate with which the PDU is sent; the values of Y2 and Z2 are given in 

clause 21 .6 for each combination. 
NOTE 2: The length of IVIAC PDU indicated by length indication 1 1 1 1OI2 is set to correspond to the normal size of an 

advanced link data segment on a QAM channel. 
NOTE 3: The immediate napping permission flag shall be present when the PDU is sent using tt/8-D8PSK or QAM 

modulation. It shall not be present when the PDU is sent using tt/4-DQPSK modulation. 
NOTE 4: The multiple slot granting flag shall be present when the slot granting flag is set to 1 and the PDU is sent 

using QAM modulation. It shall not be present when the slot granting flag is set to or the PDU is sent using 

TT/4-DQPSK orTT/8-D8PSK modulation. 
NOTE 5: The basic slot granting element shall be present when the slot granting flag is set to 1 and either the PDU is 

sent using tt/4-DQPSK or tt/8-D8PSK modulation, or the PDU is sent using QAM modulation and the multiple 

slot granting flag is set to 0. 
NOTE 6: The multiple slot granting element shall be present when the slot granting flag is set to 1 and the PDU is sent 

using QAM modulation and the multiple slot granting flag is set to 1 . 



The first two bits of the MAC header distinguish between the possible PDU types which can be sent in the downlink 
MAC block. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block or less than the size of the TM-SDU indicated by the length 
indication field. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header length. 

The position of grant element indicates the channel on which the optional slot grant is valid. If there is no slot granting 
in this PDU, the MAC shall ignore the content of this bit. 

The encryption mode field shall indicate whether or not the TM-SDU contents are encrypted and, if so, the encryption 
algorithm used. The MAC header shall not be encrypted except that, if the encryption mode field is not set to OO2: 

• the channel allocation element (when present) shall be encrypted; and 

• the address is encrypted when appropriate (for details of the address encryption method and when it is used, 

see EN 300 392-7 [8]). 

NOTE 1 : In the case of an event label assignment or usage marker assignment, the address element comprises two 
parts (SSI or SMI and event label or usage marker). The rules defined in EN 300 392-7 [8] for when 
address encryption is used apply independently to each part of the address. 

In the case of fragmentation, the setting of the encryption mode field in the MAC -RESOURCE PDU shall apply to all 
fragments of the TM-SDU. 

The random access flag shall be used for the BS to acknowledge a successful random access so as to prevent the MS 
sending further random access requests. 

The length indication field shall indicate the length of the MAC PDU which comprises the MAC PDU header and the 
TM-SDU. If the length indication field has value of 1 1 1 1 1 12, then this shall indicate the beginning of a fragmented 
signalling message. 

The units used for the length indication depend on the bandwidth, modulation and coding rate with which the PDU is 
sent; see clause 21.6. The defined values of the length indication cover up to the size of the MAC block or a 
MAC-RESOURCE PDU of up to 2 848 bits, whichever is the lesser. 

NOTE 2: A 2848-bit MAC-RESOURCE PDU can carry the maximum size of TM-SDU (2 632 bits) with a 216-bit 
MAC PDU header. A 216-bit MAC PDU header allows for most combinations of the optional elements. 
(The MAC PDU header is not restricted to 216 bits, provided that the TM-SDU length plus the MAC 
PDU header length does not exceed the maximum size of MAC-RESOURCE PDU.) 
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NOTE 3: In exceptional circumstances, if the 2848-bit limit would be exceeded due to the BS wishing to send a 
very long TM-SDU (maximum size or close to the maximum size) with a very long MAC header (more 
than 216 bits), the BS could, for example, choose to use a basic slot granting element instead of a multiple 
slot granting element (or use fewer slot granting sets). 

The address type field shall indicate the type of address(es) contained in the address field. The length of the address 
field shall be 10 bits, 24 bits, 30 bits or 34 bits depending on the type of address information contained in it. 

The immediate napping permission flag shall be present when the PDU is sent using 71/8-D8PSK or QAM modulation. 
This element indicates whether, after receiving this PDU, the MS may regard this address as eligible for napping. 

The power control flag shall indicate whether the optional power control element is present in this PDU. 

The slot granting flag shall indicate whether one of the optional slot granting elements is present in this PDU. If the slot 
granting flag is set to 1 then: 

• if the PDU is sent using 7i/4-DQPSK or 71/8-D8PSK modulation, the multiple slot granting flag shall not be 
present and the basic slot granting element shall be present; or 

• if the PDU is sent using QAM modulation, the multiple slot granting flag shall be present; then: 

if the multiple slot granting flag is set to 0, the basic slot granting element shall be present; or 

if the multiple slot granting flag is set to 1, the multiple slot granting element shall be present. 

The channel allocation flag shall indicate whether the optional channel allocation element is present in this PDU. 

The header length of a MAC-RESOURCE PDU depends on the type of address information and on which of the 
optional fields are present. When an event label is used and there are no optional fields present, the minimum header 
length shall be 29 bits if the PDU is sent using 7i/4-DQPSK modulation or 30 bits if the PDU is sent using 71/8-D8PSK 
or QAM modulation. The maximum TM-SDU length when an event label is used and there are no optional fields 
present is shown in table 21.56. 

The address type field may be used to indicate a null PDU (address type = OOO2). If a null PDU is indicated, there shall 
be no further information in the PDU after the address type field. The length of the null PDU, therefore, shall be 16 bits. 
On STCH, the length indication field may indicate whether the second half slot is stolen. Otherwise the length 
indication shall be set according to the length of the null PDU (i.e. set to OOOOIO2 if Y2 is 1 or to OOOOOI2 if Y2 is 2). 
All other fields in a null PDU (i.e. Fill bit indication. Position of grant. Encryption mode, and Random access flag) may 
be set to any value by the BS and shall be ignored by the MS in the present document). If the null PDU is present in a 
MAC block, then there shall be no subsequent PDUs in that block and any spare capacity shall be filled with fill bits. 

This PDU shall also be used for C-plane signalling using the STCH on the downlink. By default, the STCH occupies 
only the first half slot. The second half slot may also be stolen, either for the last fragment of a fragmented SDU or for 
subsequent PDUs which the MAC may have ready to send or for U-plane signalling. A length indication ofllllll2 

shall be used to indicate that the second half slot is stolen for the last fragment of a fragmented SDU. A length 
indication of 11 1 1 IO2 shall be used to indicate that the second half slot is stolen for subsequent C-plane signalling or 
U-plane signalling. The last fragment shall use the MAC -END PDU, while subsequent C-plane PDUs shall use the 
MAC-RESOURCE PDU and U-plane signalling shall use the MAC-U-SIGNAL PDU. It shall only be possible to 
fragment SDUs over the two halves of a full slot on the STCH. 
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Table 21.56: Maximum length of TM-SDU in downlink MAC-RESOURCE PDU 



Logical channel 


Maximum TIUI-SDU length [bits] 

with event label and no optional 

fields 


SCH/F 


239 


SCH/HD 


95 


STCH 


95 


SCH-P8/F 


382 


SCH-P8/HD 


166 


SCH-Q/D25-4H 


155 


SCH-Q/D25-16H 


359 


SCH-Q/D25-16U 


770 


SCH-Q/D25-64H 


563 


SCH-Q/D25-64M 


767 


SCH-Q/D25-64U 


1 178 


SCH-Q/D50-4H 


391 


SCH-Q/D50-16H 


831 


SCH-Q/D50-16U 


1 714 


SCH-Q/D50-64H 


1 271 


SCH-Q/D50-64M 


1 711 


SCH-Q/D50-64U 


2 594 


SCH-Q/D100-4H 


863 


SCH-Q/D100-16H 


1 775 


SCH-Q/D100-16U 


2 632 (see note) 


SCH-Q/D100-64H 


2 632 (see note) 


SCH-Q/D100-64M 


2 632 (see note) 


SCH-Q/D100-64U 


2 632 (see note) 


SCH-Q/D150-4H 


1 335 


SCH-Q/D150-16H 


2 632 (see note) 


SCH-Q/D150-16U 


2 632 (see note) 


SCH-Q/D150-64H 


2 632 (see note) 


SCH-Q/D150-64M 


2 632 (see note) 


SCH-Q/D150-64U 


2 632 (see note) 


NOTE: The maximum length of TM-SDU in this IVIAC blocl< is 
constrained by the maximum permitted size of TM-SDU 
(N.202) rather than by the size of the MAC blocl<. 



21.4.3.2 MAC-FRAG (downlink) 

This PDU shall be used to send continuation fragments of fragmented C-plane signalling data on the downlink using 
half slot (SCH/HD or SCH-P8/HD) or full slot (SCH/F, SCH-P8/F or SCH-Q/D) signalling. Its contents shall be as 
shown in table 21.57. 

Table 21.57: MAC-FRAG (downlink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


OI2 


MAC-FRAG or MAC-END 


MAC PDU subtype 


1 


M 





MAC-FRAG 


Fill bit indication 


1 


M 





No fill bits present 


1 


Fill bit(s) present 


TM-SDU 


varies 


M 







The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the downlink. A 
PDU subtype bit distinguishes between MAC -FRAG and MAC-END which share the same MAC PDU type. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block. 

The header length of a MAC-FRAG PDU shall be equal to 4 bits. The maximum TM-SDU length is shown in 
table 21.58. 



£75/ 



613 



ETSI TS 300 392-2 V3.3.1 (2008-10) 



Table 21.58: Maximum length of TM-SDU in downlink MAC-FRAG PDU 



Logical channel 


Maximum TM-SDU length [bits] 


SCH/F 


264 


SCH/HD 


120 


SCH-P8/F 


408 


SCH-P8/HD 


192 


SCH-Q/D25-4H 


181 


SCH-Q/D25-16H 


385 


SCH-Q/D25-16U 


796 


SCH-Q/D25-64H 


589 


SCH-Q/D25-64M 


793 


SCH-Q/D25-64U 


1 204 


SCH-Q/D50-4H 


417 


SCH-Q/D50-16H 


857 


SCH-Q/D50-16U 


1 740 


SCH-Q/D50-64H 


1 297 


SCH-Q/D50-64M 


1 737 


SCH-Q/D50-64U 


2 620 


SCH-Q/D100-4H 


889 


SCH-Q/D100-16H 


1 801 


SCH-Q/D100-16U 


Not normally applicable (see note) 


SCH-Q/D100-64H 


Not normally applicable (see note) 


SCH-Q/D100-64M 


Not normally applicable (see note) 


SCH-Q/D100-64U 


Not normally applicable (see note) 


SCH-Q/D150-4H 


1 361 


SCH-Q/D150-16H 


Not normally applicable (see note) 


SCH-Q/D150-16U 


Not normally applicable (see note) 


SCH-Q/D150-64H 


Not normally applicable (see note) 


SCH-Q/D150-64M 


Not normally applicable (see note) 


SCH-Q/D150-64U 


Not normally applicable (see note) 


NOTE: For these logical channels, the MAC block is large enough to contain the 
maximum permitted size of TIVI-SDU so the BS normally has no need to 
use MAC-FRAG. (It completes the TM-SDU using MAC-END instead.) 
However the BS may sometimes need to use MAC-FRAG if it chooses to 
include a fragment of the TM-SDU by association, after sending other 
PDU(s), such that the TM-SDU cannot be completed within the slot. 
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21.4.3.3 MAC-END (downlink) 

This PDU shall be used to send the last fragment of fragmented C-plane signalling data on the downlink in a full slot 
(SCH/F, SCH-P8/F or SCH-Q/D) or the first or second half of a full slot (SCH/HD or SCH-P8/HD). It shall also be 
used to send the last fragment of fragmented C-plane signalling in the second half of a stolen full slot on the downlink. 
Its contents shall be as shown in table 21.59. 

Table 21.59: MAC-END (downlink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


OI2 


MAC-FRAG or MAC-END 


MAC PDU subtype 


1 


M 


1 


MAC-END 


Fill bit indication 


1 


M 





No fill bits present 


1 


Fill bit(s) present 


Position of grant 


1 


M 





Slot grant is on current channel 


1 


Slot grant is on allocated channel 


Length indication 


6 


M 


0000002 


Reserved 


000001 2 


Length of MAC PDU = value x Y2 octets (see note 1) 


etc. 


etc. 


OIOOIO2 


Length of MAC PDU = value x Y2 octets 


OIOOII2 


Length of MAC PDU = (18 x Y2 + (value - 18) x Z2) octets 


etc. 


etc. 


IIIOIO2 


Length of MAC PDU = (18 x Y2 + (value - 18) x Z2) octets 


IIIOII2 


Reserved 


etc. 


etc. 


IIIIII2 


Reserved 


Immediate napping 
permission flag (see note 2) 


1 


C 





Immediate napping permission not given 


1 


Immediate napping permission given 


Slot granting flag 


1 


M 





No slot granting information elements in PDU 


1 


Slot granting information element in PDU 


Multiple slot granting flag 
(see note 3) 


1 


C 





Basic slot granting information element in PDU 


1 


Multiple slot granting information element in PDU 


Basic slot granting element 
(see note 4) 


8 


C 




See basic slot granting information element definition 


Multiple slot granting 
element (see note 5) 


varies 


c 




See multiple slot granting information element definition 


Channel allocation flag 


1 


M 





No channel allocation information element in PDU 


1 


Channel allocation information element in PDU 


Channel allocation element 


varies 


c 




See channel allocation information element definition 


TM-SDU 


varies 


c 






NOTE 1 : For values of length indication up to 01 001 O2, the unit of the length indication is Y2 octets whereas, for higher 

values, the incremental unit of the length indication is Z2 octets. The values of Y2 and Z2 depend on the 

bandwidth, modulation and coding rate with which the PDU is sent; the values of Y2 and Z2 are given in 

clause 21 .6 for each combination. 
NOTE 2: The immediate napping permission flag shall be present when the PDU is sent using tt/8-D8PSK or QAM 

modulation. It shall not be present when the PDU is sent using tt/4-DQPSK modulation. 
NOTE 3: The multiple slot granting flag shall be present when the slot granting flag is set to 1 and the PDU is sent 

using QAM modulation. It shall not be present when the slot granting flag is set to or the PDU is sent using 

TT/4-DQPSK orTT/8-D8PSK modulation. 
NOTE 4: The basic slot granting element shall be present when the slot granting flag is set to 1 and either the PDU is 

sent using tt/4-DQPSK or tt/8-D8PSK modulation, or the PDU is sent using QAM modulation and the multiple 

slot granting flag is set to 0. 
NOTE 5: The multiple slot granting element shall be present when the slot granting flag is set to 1 and the PDU is sent 

using QAM modulation and the multiple slot granting flag is set to 1 . 



The first two bits of the MAC header shall distinguish between the possible PDU types which can be sent on the 
downlink. A PDU subtype bit distinguishes between MAC-FRAG and MAC-END which share the same MAC PDU 
type. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block or less than the size of the TM-SDU indicated by the length 
indication field. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header length. 
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The position of grant element indicates the channel on which the optional slot grant is valid. If there is no slot granting 
in this PDU, the MAC shall ignore the content of this bit. 

The length indication field shall indicate the length of the MAC PDU which comprises the MAC PDU header and the 
TM-SDU. 

The units used for the length indication depend on the bandwidth, modulation and coding rate with which the PDU is 
sent; see clause 21.6. The defined values of the length indication cover up to the size of the MAC block or the 
maximum size of a MAC -END PDU, whichever is the lesser. 

The immediate napping permission flag shall be present when the PDU is sent using 71/8-D8PSK or QAM modulation. 
This element indicates whether, after receiving this PDU, the MS may regard this address as eligible for napping. 

The slot granting flag shall indicate whether one of the optional slot granting elements is present in this PDU. The slot 
granting element may be used to allocate some uplink reserved slots for an MS. If the slot granting flag is set to 1 then: 

• if the PDU is sent using 7i/4-DQPSK or 71/8-D8PSK modulation, the multiple slot granting flag shall not be 
present and the basic slot granting element shall be present; or 

• if the PDU is sent using QAM modulation, the multiple slot granting flag shall be present; then: 

if the multiple slot granting flag is set to 0, the basic slot granting element shall be present; or 

if the multiple slot granting flag is set to 1, the multiple slot granting element shall be present. 

The channel allocation flag shall indicate whether the channel allocation element is present in this PDU. The channel 
allocation element may be used to direct MS to a channel at the end of a fragmented downlink message. 

The minimum header length of a MAC -END PDU shall be equal to 13 bits when sent using 7i/4-DQPSK modulation or 
14 bits when sent using 71/8-D8PSK or QAM modulation. The maximum TM-SDU length is shown in table 21.60. 
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Table 21.60: Maximum length of TM-SDU in downlink MAC-END PDU 



Logical channel 


Maximum TM-SDU length [bits] 
if no optional fields 


SCH/F 


255 


SCH/HD 


111 


STCH 


111 


SCH-P8/F 


398 


SCH-P8/HD 


182 


SCH-Q/D25-4H 


171 


SCH-Q/D25-16H 


375 


SCH-Q/D25-16U 


786 


SCH-Q/D25-64H 


579 


SCH-Q/D25-64M 


783 


SCH-Q/D25-64U 


1 194 


SCH-Q/D50-4H 


407 


SCH-Q/D50-16H 


847 


SCH-Q/D50-16U 


1 730 


SCH-Q/D50-64H 


1 287 


SCH-Q/D50-64M 


1 727 


SCH-Q/D50-64U 


2610 


SCH-Q/D100-4H 


879 


SCH-Q/D100-16H 


1 791 


SCH-Q/D100-16U 


2 631 (see note) 


SCH-Q/D100-64H 


2 631 (see note) 


SCH-Q/D100-64M 


2 631 (see note) 


SCH-Q/D100-64U 


2 631 (see note) 


SCH-Q/D150-4H 


1 351 


SCH-Q/D150-16H 


2 631 (see note) 


SCH-Q/D150-16U 


2 631 (see note) 


SCH-Q/D150-64H 


2 631 (see note) 


SCH-Q/D150-64M 


2 631 (see note) 


SCH-Q/D150-64U 


2 631 (see note) 


NOTE: The maximum length of TM-SDU in this IVIAC blocl< is 
constrained by the maximum permitted size of TM-SDU 
(N.202) rather than by the size of the MAC blocl<. 



21.4.3.4 



MAC-D-BLCK 



This PDU may optionally be used to send C-plane signalling data on the downlink in a full slot (SCH/F, SCH-P8/F or 
SCH-Q/D) in cases when an event label can be used and a pre-defined length is appropriate e.g. when sending an 
advanced link data segment. The MAC-D-BLCK PDU has a smaller MAC header than the MAC-RESOURCE PDU so 
can carry more data. 

The MAC-D-BLCK PDU should not be used when the pre-defmed length is not appropriate. For example, when the BS 
is sending a basic link message or a short advanced link message or the last segment of an advanced link message, use 
of the MAC -RESOURCE PDU may be more efficient. 

The MAC-D-BLCK PDU cannot be used if any of the following functions are needed: 

SSI or SMI addressing; 

fragmentation; 

acknowledgement of random access; 

event label or usage marker assignment; 

power control; 

channel allocation; or 

null PDU. 
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When any of these functions are needed, the BS should use the MAC-RESOURCE PDU. 

The MAC-D-BLCK PDU uses the same MAC PDU type as the MAC-U-SIGNAL PDU, which is sent using the 
steaHng channel (STCH). The MAC-D-BLCK PDU shall not be sent on STCH, SCH/HD or SCH-P8/HD. 

The contents of the MAC-D-BLCK PDU shall be as shown in table 21.61. 

Table 21.61 : MAC-D-BLCK PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


112 


Supplementary MAC PDU 


Supplementary MAC 
PDU subtype 


1 


M 





MAC-D-BLCK 


Fill bit indication 


1 


M 





No fill bit present 


1 


Fill bit(s) present 


Encryption mode 


2 


M 


002 


Not encrypted 


012 


See EN 300 392-7 [8] 


102 


See EN 300 392-7 [8] 


112 


See EN 300 392-7 [8] 


Address 


10 


M 




Event label 


Immediate napping 
permission flag 


1 


M 





Immediate napping permission not given 


1 


Immediate napping permission given 


Slot granting flag. 


1 


M 





No slot granting information element in PDU 


1 


Slot granting information element in PDU 


Basic slot granting 
element (see note) 


8 


C 




See basic slot granting information element definition 


TM-SDU 


varies 


C 






NOTE: The basic slot granting element shall be present when the slot granting flag is set to 1 . 



The length of the MAC-D-BLCK PDU is defined implicitly, as shown in table 21.62. The implicit length shall refer to 
the length of the MAC PDU, which comprises the MAC PDU header and the TM-SDU. For a 7i/4-DQPSK or 
71/8-D8PSK slot, the implicit length matches the size of the MAC block. On a QAM channel, the implicit length of the 
MAC-D-BLCK PDU is set to correspond to the normal size of an advanced link data segment i.e. 

• in the case of a 25 kHz or 50 kHz channel, the implicit length corresponds to the size of a 4-QAM rate = 1/2 
full-slot MAC block at the current bandwidth; 

• in the case of a 100 kHz or 150 kHz channel, the implicit length corresponds to half the size of a 4-QAM 
rate = 1/2 full-slot MAC block at the current bandwidth. 

Table 21.62: Implicit length of MAC-D-BLCK PDU 



Logical channel 


Implicit length of MAC-D-BLCK PDU 


SCH/F 


268 bits 


SCH-P8/F 


412 bits 


SCH-Q/D25 


185 bits 


SCH-Q/D50 


421 bits 


SCH-Q/D100 


446 bits 


SCH-Q/D150 


682 bits 



The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the downlink 
SCH/F, SCH-P8/F or SCH-Q/D. The supplementary MAC PDU subtype bit distinguishes between supplementary MAC 
PDUs which share the same MAC PDU type. 

The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the TM-SDU is 
less than the available capacity of the MAC block or less than the size of the TM-SDU indicated by the implicit length 
of the MAC-D-BLCK PDU. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header 
length. 

The encryption mode field shall indicate whether or not the TM-SDU contents are encrypted and, if so, the encryption 
algorithm used. The MAC header shall not be encrypted. 
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The address field shall contain an event label. 

NOTE 1: As defined in EN 300 392-7 [8], the event label is not encrypted. 

The immediate napping permission flag shall indicate whether, after receiving this PDU, the MS may regard this 
address as eligible for napping. 

The slot granting flag shall indicate whether the optional basic slot granting element is present in this PDU. 

NOTE 2: The BS may cut an advanced link TL-SDU into segments using the assumption that it will not include a 
slot grant until the end of the TL-SDU. Alternatively it may cut the TL-SDU into segments allowing for a 
possible slot grant and then include fill bits when the basic slot granting element is not present. 

The header length of a MAC-D-BLCK PDU shall be equal to 18 bits if a basic slot granting element is not included. 
The maximum TM-SDU length is shown in table 21.63. 

Table 21.63: Maximum length of TM-SDU in MAC-D-BLCK PDU 



Logical channel 


Maximum TM-SDU length [bits] 


SCH/F 


250 


SCH-P8/F 


394 


SCH-Q/D25 


167 


SCH-Q/D50 


403 


SCH-Q/D100 


428 


SCH-Q/D150 


664 



21 .4.4 TMB-SAP: MAC PDU structure for broadcast 

Broadcast PDUs shall be used by the BS to send some broadcast information on the downlink to all MSs. There shall be 
no addresses contained in these PDUs and all MSs shall decode them as if they were addressed to each of them. The 
SYNC PDU shall be transmitted using the BSCH which shall be sent using the synchronization burst. There is no PDU 
type element in the SYNC PDU. The other broadcast PDU types shall be distinguished by a PDU type and broadcast 
type as shown in table 21.64. 

Table 21.64: Broadcast PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


IO2 


Broadcast PDU 


Broadcast type 


2 


M 


OO2 


SYSINFO PDU if sent using tt/4-DQPSK modulation 
(BNCH content) orTT/8-D8PSK modulation; or 
SYSINFO-Q PDU if sent using QAM modulation 
(BNCH-Q content) 


OI2 


ACCESS-DEFINE PDU 


IO2 


Reserved 


II2 


Reserved 


Broadcast elements 








See following definitions for SYSINFO, SYSINFO-Q 
and ACCESS-DEFINE PDUs 



The following clauses describe the contents of the three types of broadcast PDU. 



21.4.4.1 



SYSINFO 



The SYSINFO PDU shall be transmitted using the BNCH on SCH/HD. It may also be sent using the stealing channel 
(STCH). It may also be sent using association on SCH-P8/HD or SCH-P8/F. Its contents shall be as shown in 
table 21.65. 

NOTE 1: The SYSINFO PDU is sent on 7i/4-DQPSK and D8PSK channels. It is sent using 7i/4-DQPSK modulation 
on 71/4-DQPSK channels. It is also sent using 7i/4-DQPSK modulation on D8PSK channels according to a 
mandatory mapping, but it may be sent using 31/8-D8PSK modulation in other positions. 
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Table 21.65: SYSINFO PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


IO2 


Broadcast PDU 


Broadcast type 


2 


M 


OO2 


SYSINFO PDU 


Main carrier 


12 


M 




Frequency of the MCCH 


Frequency band 


4 


M 




Frequency band of the MCCH 


Offset 


2 


M 


OO2 


kHz offset 


OI2 


+6,25 kHz offset 


IO2 


-6,25 kHz offset 


II2 


+12,5 kHz offset 


Duplex spacing 


3 


M 




Provision for different duplex spacing 


Reverse operation 


1 


M 





Normal 


1 


Reverse 


Number of common 
secondary control channels 
in use on main carrier 


2 


M 


OO2 


None 


OI2 


Timeslot 2 of main carrier 


IO2 


Timeslots 2 and 3 of main carrier 


II2 


Timeslots 2, 3 and 4 of main carrier 


MS_TXPWR_MAX_CELL 
(see note 1 ) 


3 


M 


OOO2 


Reserved 


001 2 


15dBm 


etc. 


etc. 


III2 


45 dBm (5 dB steps) 


RXLEV_ACCESS_MIN 
(see note 1) 


4 


M 


OOOO2 


-125 dBm 


etc. 


etc. 


IIII2 


-50 dBm (5 dB steps) 


ACCESS_PARAMETER 
(see note 1) 


4 


M 


OOOO2 


-53 dBm 


etc. 


etc. 


IIII2 


-23 dBm (2 dB steps) 


RADIO DOWNLINK 
TIMEOUT (see note 1) 


4 


M 


OOOO2 


Disable radio downlink counter 


OOOI2 


144 timeslots 


001 O2 


288 timeslots 


etc. 


etc. 


IIII2 


2 160 timeslots (multiples of 144) 


Hyperframe / 
cipher key flag 


1 


M 





Hyperframe number 


1 


Common cipher key identifier 


Hyperframe number 


16 


C 




Cyclic count of hyperframes 


CCK identifier or static cipher 
key version number 


16 


C 




Common cipher key identifier or static cipher key 
version number, refer to EN 300 392-7 [8] 


Optional field flag 


2 


M 


OO2 


Even multiframe definition for TS mode 


OI2 


Odd multiframe definition for TS mode 


IO2 


Default definition for access code A 


II2 


Extended services broadcast 


TS_COMMON_FRAMES 
either for Even or Odd 
multiframes 


20 


C 




Bit map of common frames for TS mode, see 
information element description in table 21 .89 


Default definition for access 
code A 


20 


C 




See table 21.66 


Extended services broadcast 


20 


C 




See table 21 .67 


Reserved (see note 2) 


28 


C 




Reserved, value shall be set to all zeros 


TM-SDU (MLE data) 


42 


M 




As defined in clause 18 (D-MLE-SYSINFO) 


NOTE 1 : When sent on a D8PSK channel, the value of this element is specific to that D8PSK channel and may be 

different from the value for a tt/4-DQPSK channel. 
NOTE 2: This element shall be present when the PDU is sent using tt/8-D8PSK modulation. This element shall not 

be present when the PDU is sent using tt/4-DOPSK modulation. 



£75/ 



620 ETSI TS 300 392-2 V3.3.1 (2008-10) 

The frequency of the main carrier shall be defined by the following information elements: 

main carrier; 

frequency band; 

offset; 

duplex spacing; 

reverse operation. 

The frequency band field shall map to a specific frequency which shall map to a defined base frequency (in MHz) for 
the carrier numbering scheme. The main carrier field shall indicate the carrier frequency relative to the base frequency 
defined by the frequency band field. The main carrier field shall have step size of 25 kHz. The offset field shall then 
adjust the main carrier frequency by the given amount. (The offset field allows for the case where the carrier frequency 
is not N X 25 kHz above the base frequency.) The frequency so defined shall be the downlink frequency of the main 
carrier. This calculation is summarized by the following equation: 

• downlink main carrier frequency = base frequency + (main carrier x 25 kHz) + offset kHz. 

The uplink frequency of the main carrier shall be determined using the duplex spacing and reverse operation fields. The 
duplex spacing field shall map to a defined duplex spacing (in MHz) for the carrier numbering scheme. The duplex 
spacing shall be dependent on the frequency band element. The reverse operation field shall indicate whether to add or 
subtract the duplex spacing to arrive at the uplink frequency of the main carrier. If normal operation, the duplex spacing 
shall be subtracted. If reverse operation, the duplex spacing shall be added. This calculation is summarized by the 
following equations: 

• normal operation: 

uplink main carrier frequency = downlink main carrier frequency - duplex spacing. 

• reverse operation: 

uplink main carrier frequency = downlink main carrier frequency + duplex spacing. 

The mappings of the frequency band field values to actual base frequencies and the duplex spacing field values to actual 
duplex frequency spacing are defined in TS 100 392-15 [18]. 

NOTE 2: These rules for calculation of uplink and downlink carrier frequency are also used for calculation of the 
uplink and downlink main carrier frequency from the elements in the SYSINFO-Q PDU. 

RXLEV_ACCESS_MIN shall be used for cell selection and reselection. ACCESS_PARAMETER shall be used for 
subsequent power adjustments. MS_TXPWR_MAX_CELL shall be used for cell selection and reselection, and for 
power adjustments. RADIO_DOWNLINK_TIMEOUT shall be used in the criteria for radio downlink failure. 

The hyperframe/cipher key flag shall indicate whether the following information element is the hyperframe number 
information element or the CCK identifier or static cipher key version number information element. The usage of the 
CCK identifier or static cipher key version number information element is defined in EN 300 392-7 [8]. 

The optional field flag information element indicates which one of the optional information elements is present. 

The TS_COMMON_FRAMES information element shall only be present if "Discontinuous TX" and "MCCH sharing" 
is indicated in the SYNC broadcast PDU. The optional field shall indicate whether TS_COMMON_FRAMES refers to 
odd or even multiframe definition. 

If the optional field flag indicates a default access definition, then the 20-bit field corresponding to the default access 
code definition for access code A shall be present. Its contents shall be as defined in table 21.66. 
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Table 21.66: Default definition for access code A information element contents 



Information element 


Length 


Type 


Value 


Remark 


IMM (immediate) 


4 


M 


OOOO2 


Always randomize 


OOOI2 


Randomize after IIVIM TDMA frames 


etc. 


etc. 


111 O2 


Randomize after IIVIM TDMA frames 


IIII2 


Immediate access allowed 


WT (waiting time) 


4 


M 


OOOO2 


Reserved 


OOOI2 


Response within WT downlink opportunities 


etc. 


etc. 


IIII2 


Response within WT downlink opportunities 


Nu (number of random 
access transmissions on 
uplinl<) 


4 


M 


OOOO2 


No random access transmission allowed 


OOOI2 


1 random access transmission allowed 


etc. 


etc. 


IIII2 


15 random access transmissions allowed 


Frame-length factor 


1 


M 





Multiply base frame-length by 1 


1 


Multiply base frame-length by 4 


Timeslot pointer 


4 


M 


OOOO2 


Same as downlink slot assignment 


OOOI2 


Timeslot 4 


001 O2 


Timeslot bit map 


etc. 


etc. 


IIIO2 


Timeslot bit map 


IIII2 


All fourtimeslots 


IVIinimum PDU priority 


3 


M 


OOO2 


Priority (lowest) 


etc. 


etc. 


III2 


Priority 7 (highest) 



If optional field flag indicates an extended service broadcast, the bits shall be used to indicate the extended services 
provided according to table 21.67. In the present document only the extended services broadcast sections 1 and 2 may 
be used. 

NOTE 3: The extended services broadcast sections 3 and 4 are not used in the present document. The setting of the 
reserved bits to OOOOOOO2 in tables 21.70 and 21.71 does not limit how those bits will be used in future 
editions of the present document. 
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Table 21.67: Extended services broadcast information element 



Information element 


Length 


M/C/0 


Value 


Remark 


Security information 


8 






Refer to EN 300 392-7 [8]. 


SDS-TL addressing 
metliod 


2 


M 


OO2 


Reserved 


OI2 


Service centre addressing preferred (see note 1 ) 


IO2 


Never use service centre addressing (see note 1) 


II2 


MS choice to use service centre addressing (see note 1) 


GCK supported 


1 


M 




Refer to EN 300 392-7 [8] (see note 2) 


Section 


2 


M 


OO2 


Extended services broadcast section 1 is present 


OI2 


Extended services broadcast section 2 is present 


IO2 


Extended services broadcast section 3 is present 


II2 


Extended services broadcast section 4 is present 


Extended services 
broadcast section 1 
(see note 3) 


7 


C 




See table 21.68 


Extended services 
broadcast section 2 
(see note 4) 


7 


C 




See table 21 .69 


Extended services 
broadcast section 3 
(see note 5) 


7 


C 




See table 21.70 


Extended services 
broadcast section 4 
(see note 6) 


7 


C 




See table 21.71 


N0TE1 
NOTE 2 
NOTE 3 
NOTE 4 
NOTES 
NOTE 6 


Refer to clause 29 for further information. 

This shall be ignored by the IVIS when A! encryption is not available (indicated in BS Service Details). 

This element shall be present only if section element is set to OO2. 

This element shall be present only if section element is set to 01 2- 

This element shall be present only if section element is set to 1 02. 

This element shall be present only if section element is set to 1 12- 



Table 21.68: Extended services broadcast section 1 information element 



Information element 


Length 


M/C/0 


Value 


Remark 


Data priority supported 




M 





Data priority not supported on this cell 


1 


Data priority supported on this cell 


Extended advanced links 
and MAC-U-BLCK 
supported 




M 





Extended advanced links and MAC-U-BLCK PDU not 
supported on this cell (see note 1) 


1 


Extended advanced links and MAC-U-BLCK PDU supported 
on this cell (see note 2) 


OoS negotiation 
supported (see note 3) 




M 





QoS negotiation not supported on this cell 


1 


QoS negotiation supported on this cell 


D8PSK service 




M 





D8PSK operation not supported on this cell 


1 


D8PSK operation supported on this cell 


Section 2 information 
sent on this cell 




M 





No information in extended services broadcast section 2 


1 


Further information in extended services broadcast section 2 


Section 3 information 
sent on this cell 




M 





No information in extended services broadcast section 3 


1 


Further information in extended services broadcast section 3 


Section 4 information 
sent on this cell 




M 





No information in extended services broadcast section 4 


1 


Further information in extended services broadcast section 4 


NOTE 1 : If the "extended advanced links and MAC-U-BLCK supported" element is set to 0, this indicates that the BS 
does not support extended advanced links and does not support the MAC-U-BLCK PDU. The BS may 
support the original advanced link (see the "BS service details" element in clause 18.5.2). 

NOTE 2: If the "extended advanced links and MAC-U-BLCK supported" element is set to 1 , this indicates that the BS 
supports four extended advanced links for each service and for each MS address, and supports the original 
advanced link plus three extended advanced links for each service and for each MS address; it also indicates 
that the BS supports the MAC-U-BLCK PDU (if it has assigned an event label to the MS). 

NOTE 3: Support of QoS negotiation is needed if D8PSK and/or QAM operation are supported. 
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Table 21.69: Extended services broadcast section 2 information element 



Information element 


Length 


M/C/0 


Value 


Remark 


25 kHz QAM service 


1 


M 





25 kHz QAM operation not supported on this cell 


1 


25 kHz QAM operation supported on this cell 


50 kHz QAM service 


1 


M 





50 kHz QAM operation not supported on this cell 


1 


50 kHz QAM operation supported on this cell 


1 00 kHz QAM service 


1 


M 





100 kHz QAM operation not supported on this cell 


1 


100 kHz QAM operation supported on this cell 


1 50 kHz QAM service 


1 


M 





150 kHz QAM operation not supported on this cell 


1 


150 kHz QAM operation supported on this cell 


Reserved 


3 


M 




Reserved, value shall be set to OOO2 



Table 21.70: Extended services broadcast section 3 information element 



Information element 


Length 


M/C/0 


Value 


Remark 


Reserved 


7 


M 




Reserved, value shall be set to OOOOOOO2 



Table 21 .71 : Extended services broadcast section 4 information element 



Information element 


Length 


M/C/0 


Value 


Remark 


Reserved 


7 


M 




Reserved, value shall be set to OOOOOOO2 



Each of the optional fields comprises 20 bits (including reserved bits). Therefore, when the SYSINFO PDU is sent 
using 7I/4-DQPSK modulation, it fully occupies all 124 bits of the MAC block in all cases. 

When the SYSINFO PDU is sent using 71/8-D8PSK modulation, there is an additional reserved element. Therefore, 
when the SYSINFO PDU is sent using 71/8-D8PSK modulation, the PDU length is 152 bits. 
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21.4.4.1a SYSINFO-Q 

The SYSINFO-Q PDU may be transmitted by the BS to send broadcast information on a QAM channel. 

The SYSINFO-Q PDU shall use the BNCH-Q on SCH-Q/D. It fully occupies a 4-QAM rate = 1/2 SCH-Q/D MAC 
block on a 25 kHz QAM channel (logical channel SCH-Q/D25-4H). It may be sent using PDU association within other 
SCH-Q/D MAC blocks (i.e. higher modulation level and/or bandwidth). Its contents shall be as shown in table 21.72. 

NOTE: The SYSINFO-Q PDU may be sent on QAM channels. It is always sent using QAM modulation. 

Table 21.72: SYSINFO-Q PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


IO2 


Broadcast PDU 


Broadcast type 


2 


M 


OO2 


SYSINFO-Q PDU 


Main carrier 


12 


M 




Frequency of the MCCH 


Frequency band 


4 


M 




Frequency band of the MCCH 


Offset 


2 


M 


OO2 


kHz offset 


OI2 


+6,25 kHz offset 


IO2 


-6,25 kHz offset 


II2 


+12,5 kHz offset 


Duplex spacing 


3 


M 




Provision for different duplex spacing 


Reverse operation 


1 


M 





Normal 


1 


Reverse 


Number of common 
secondary control channels 
in use on main carrier 


2 


M 


OO2 


None 


OI2 


Timeslot 2 of main carrier 


IO2 


Timeslots 2 and 3 of main carrier 


II2 


Timeslots 2, 3 and 4 of main carrier 


MS_TXPWR_MAX_CELL on 
QAM carrier 


3 


M 


OOO2 


Reserved 


001 2 


15dBm 


etc. 


etc. 


III2 


45 dBm (5 dB steps) 


RXLEV_ACCESS_MIN on 
QAM carrier 


4 


M 


OOOO2 


-125 dBm 


etc. 


etc. 


IIII2 


-50 dBm (5 dB steps) 


ACCESS_PARAMETER on 
QAM carrier 


4 


M 


OOOO2 


-53 dBm 


etc. 


etc. 


IIII2 


-23 dBm (2 dB steps) 


RADIO DOWNLINK 
TIMEOUT on QAM carrier 


4 


M 


OOOO2 


Disable radio downlink counter 


OOOI2 


144 timeslots 


001 O2 


288 timeslots 


etc. 


etc. 


IIII2 


2 160 timeslots (multiples of 144) 


CCK identifier or static cipher 
key version number 


16 


M 




Common cipher key identifier or static cipher key 
version number, refer to EN 300 392-7 [8] 


Default definition for access 
code A 


20 


M 




See table 21.66 


Extended services broadcast 


20 


M 




See table 21 .67 


Reserved 


39 


M 




Reserved, value shall be set to all zeros 


TM-SDU (MLE data) 


47 


M 




As defined in clause 18 (D-MLE-SYSINFO-Q) 



£75/ 



625 ETSI TS 300 392-2 V3.3.1 (2008-10) 

The frequency of the main carrier shall be defined by the following information elements: 

main carrier; 

frequency band; 

offset; 

duplex spacing; 

reverse operation. 

The downlink and uplink main carrier frequency shall be calculated using the same equations as defined for the main 
carrier frequency calculation in the SYSINFO PDU description; see clause 21.4.4.1. 

RXLEV_ACCESS_MIN shall be used in the calculation of the path loss on the QAM channel. 

ACCESS_PARAMETER shall be used for power adjustments on the QAM channel. MS_TXPWR_MAX_CELL shall 
be used in the calculation of the path loss on the QAM channel, and for power adjustments on the QAM channel. 
RADIO_DOWNLINK_TIMEOUT shall be used in the criteria for radio downlink failure of the QAM channel. 

The usage of the CCK identifier or static cipher key version number information element is defined in 

EN 300 392-7 [8]. 

The contents of the default definition for access code A information element shall be as defined in table 21.66. 

The contents of the extended services broadcast information element shall be as defined in table 21.67. 

The size of the SYSINFO-Q PDU is 185 bits. Therefore, when the SYSINFO-Q PDU is sent using 4-QAM rate = 1/2 
on a 25 kHz channel, it fully occupies all 185 bits of the MAC block (SCH-Q/D25-4H). When the SYSINFO-Q PDU is 
sent using a higher modulation level and/or bandwidth, it may be sent with other PDU(s) in the SCH-Q/D MAC block 
using PDU association. 

21.4.4.2 SYNC 

The SYNC PDU shall be transmitted using the BSCH and so shall be distinguishable by the synchronization burst 
which has a special training sequence. Its contents shall be as shown in table 21.73. 

NOTE: The SYNC PDU is sent on 3i/4-DQPSK and D8PSK channels. It is always sent using 7i/4-DQPSK 
modulation. 

The sharing mode field shall indicate whether the BS is using continuous transmission, carrier sharing, MCCH sharing 
or traffic carrier sharing. If MCCH sharing is indicated, the TS reserved frames field shall indicate which frames are 
reserved in this mode of operation. For the other values of sharing mode, the contents of the TS reserved frames field 
shall be ignored. 

The frame 18 extension element shall indicate whether an MS is allowed to receive downlink information on all slots of 
the frame 18. If extension is allowed, only MSs which are capable of receiving consecutive slots are able to perform this 
function. 

The U-plane DTX flag shall indicate whether discontinuous U-plane transmission is supported on traffic channels. 
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Table 21.73: SYNC PDU contents 



Information element 


Length 


Type 


Value 


Remark 


System code 


4 


M 


OOOO2 


ETS 300 392-2 ed. 1 (no security functions) 


0001 2 


ETS 300 392-2 ed. 1 and EN 300 392-7 [8] V2.1 .1 


001 O2 


EN 300 392-2 V2.3.2 to V2.6.1 , and 
EN 300 392-7 [8] V2.1 .1 to V2.4.1 


0011 2 


EN 300 392-2 V3.1 .1 to V3.3.1 and EN 300 392-7 [8] 
V3.1.1 


0XXX2 


Other XXX2 values V-i-D reserved 


100y2 


Reserved 


101y2 


Direct Mode Operation, see EN/ETS 300 396 (DMO) 


IIZZ2 


Direct Mode Operation, see EN/ETS 300 396 


Colour code 


6 


M 


OOOOOO2 


Pre-defined scrambling, see note 


000001 2 


Operator defined scrambling, for cell identifier and 
scrambling process as defined in clause 8 


etc. 


etc. 


IIIIII2 


Operator defined scrambling, for cell identifier and 
scrambling process as defined in clause 8 


Timeslot number 


2 


M 


OO2 


Timeslot 1 


OI2 


Timeslot 2 


IO2 


Timeslot 3 


II2 


Timeslot 4 


Frame number 


5 


M 


OOOOO2 


Reserved 


00001 2 


Frame 1 


etc. 


etc. 


IOOIO2 


Frame 18 


Others 


Reserved 


Multiframe number 


6 


M 


OOOOOO2 


Reserved 


000001 2 


Multiframe 1 


etc. 


etc. 


1 1 1 1 OO2 


Multiframe 60 


Others 


Reserved 


Sharing mode 


2 


M 


OO2 


Continuous transmission 


OI2 


Carrier sharing 


IO2 


MCCH sharing 


II2 


Traffic carrier sharing 


TS reserved frames 


3 


M 


OOO2 


1 frame reserved per 2 multiframes 


OOI2 


2 frames reserved per 2 multiframes 


01 O2 


3 frames reserved per 2 multiframes 


OII2 


4 frames reserved per 2 multiframes 


IOO2 


6 frames reserved per 2 multiframes 


IOI2 


9 frames reserved per 2 multiframes 


IIO2 


12 frames reserved per 2 multiframes 


III2 


18 frames reserved per 2 multiframes 


U-plane DTX 


1 


M 





Discontinuous U-plane transmission is not allowed 


1 


Discontinuous U-plane transmission is allowed 


Frame 18 extension 


1 


M 





No frame 18 extension 


1 


Frame 18 extension allowed 


Reserved 


1 


M 





Default value 


1 


Not used in the present document 


TIVI-SDU (IVILE data) 


29 


M 




As defined in clause 18 (D-MLE-SYNC) 


NOTE: The element Colour code with the value "Predefined scrambling" means that all 30 bits of the 
scrambling vector are zeros. 
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21.4.4.3 



ACCESS-DEFINE 



The ACCESS-DEFINE PDU may be sent by the BS using a half slot or full slot on the downlink (SCH/HD, 
SCH-P8/HD, SCH/F, SCH-P8/F or SCH-Q/D) or on downlink STCH. It defines the random access parameters for the 
specified access code. Its contents shall be as shown in table 21.74. 

Table 21.74: ACCESS-DEFINE PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


IO2 


Broadcast PDU 


Broadcast type 


2 


M 


OI2 


ACCESS-DEFINE PDU 


Common or assigned control 
channel flag 


1 


M 





ACCESS-DEFINE applies to common channel 


1 


ACCESS-DEFINE applies to assigned channel 


Access code 


2 


M 


OO2 


Access code A 


OI2 


Access code B 


IO2 


Access code C 


II2 


Access code D 


IMM (immediate) 


4 


M 


OOOO2 


Always randomize 


0001 2 


Randomize after IMM TDMA frames 


etc. 


etc. 


IIIO2 


Randomize after IMM TDMA frames 


IIII2 


Immediate access allowed 


WT (waiting time) 


4 


M 


OOOO2 


Reserved 


0001 2 


Response within WT downlink opportunities 


etc. 


etc. 


IIII2 


Response within WT downlink opportunities 


Nu (number of random access 
transmissions on uplink) 


4 


M 


OOOO2 


No random access transmission allowed 


0001 2 


1 random access transmission allowed 


etc. 


etc. 


IIII2 


15 random access transmissions allowed 


Frame-length factor 


1 


M 





Multiply base frame-length by 1 


1 


Multiply base frame-length by 4 


Timeslot pointer 


4 


M 


OOOO2 


Same as downlink slot assignment 


0001 2 


Timeslot 4 


001 O2 


Timeslot bit map 


etc. 


etc. 


IIIO2 


Timeslot bit map 


IIII2 


All four timeslots 


IVIinimum PDU priority 


3 


M 


OOO2 


Priority (lowest) 


etc. 


etc. 


III2 


Priority 7 (highest) 


Optional field flag 


2 


M 


OO2 


None 


OI2 


Subscriber class bit map 


IO2 


GSSI 


II2 


Reserved, see note 


Subscriber class bit map 


16 


C 




as defined in clause 18 


GSSI 


24 


C 




Group short subscriber identity 


Filler bits 


3 


M 


IOO2 


Reserved bits to make the PDU octet bounded 


NOTE: Values OO2 and 1 1 2 indicate that there is no added optional field. 



The definition of the various random access parameters is as follows: 

• common or assigned flag: 

this indicates whether the ACCESS-DEFINE PDU applies to MSs using the channel for common control 
or MSs using it for assigned control; 
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access code: 

this is used in the ACCESS-ASSIGN message to control access for a subdivision of the MS population; 

IMM: 

this is the Aloha parameter defining when the MS may use the first valid access opportunity for its first 
random access transmission. This time is counted in terms of TDMA frames; 



WT: 



this is the Aloha parameter defining the waiting time before the MS decides to initiate an access re-try. 
This time is counted in terms of BS downlink signalling opportunities for this control channel; 



Nu: 



this is the Aloha parameter giving the number of random access transmissions an MS may send before 
abandoning the random access attempt; 

• frame-length factor: 

this is a multiplying factor appUed to the base frame-length contained in the ACCESS-ASSIGN message; 

• timeslot pointer: 

this is a pointer to where the ACCESS-ASSIGN message shall be monitored. 

21 .4.5 TMD-SAP: MAC PDU structure for U-plane signalling 

The MAC-U-SIGNAL PDU shall be used on the uplink and downlink for sending U-plane signalling information. This 
PDU shall only be sent using the STCH in conjunction with an established circuit mode. Its contents shall be as shown 
in table 21.75. 

Table 21 .75: MAC-U-SIGNAL PDU contents 



Information element 


Length 


Type 


Value 


Remark 


MAC PDU type 


2 


M 


II2 


MAC-U-SIGNAL 


Second half slot stolen flag 


1 


M 





Second half slot not stolen 


1 


Second half slot stolen 


TM-SDU 


121 


M 







The first two bits of the MAC header shall distinguish this PDU as a MAC-U-SIGNAL PDU. The second half slot 
stolen flag shall indicate whether the second half of the full slot is also stolen. If the second half is stolen it may contain 
U-plane or C-plane signalling as indicated by the MAC header. The SDU contains the user information which is 
received from the U-plane for transmission in this PDU or passed to the U-plane on receipt of this PDU. It shall be the 
responsibility of the user application at the higher layer to specify the meaning of the contents of the TM-SDU. The 
TM-SDU length shall always be 121 bits. If the user application requires fewer bits, it is the responsibility of that 
application to insert filler bits to ensure a 121 -bit TM-SDU length. 

If MAC-U-SIGNAL is sent in the second half of a full slot, the second half slot stolen flag shall still be present but its 
content shall be ignored. 

21 .4.6 TMD-SAP: MAC PDU structure for U-plane traffic 

The MAC-TRAFFIC PDU shall be used for sending U-plane traffic data on the uplink and downlink using TCH/S, 
TCH/7,2, TCH/4,8 or TCH/2,4. This PDU has no MAC header and all capacity shall be devoted to traffic information 
passed to and from the U-plane. When the MAC is in traffic mode, this PDU type shall be assumed unless the slot flag 
indicates the presence of the STCH. 

When stealing does not occur, the MAC-TRAFFIC PDU shall occupy the full slot. If stealing occurs, and only the first 
half of the slot is stolen, the MAC-TRAFFIC PDU shall occupy the second half of the slot. 
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21 .4.7 MAC PDU structure for access assignment broadcast 
21 .4.7.1 Contents of AACH-Q logical channel 

The AACH-Q shall be sent by the BS on every downlink slot of a QAM channel (except slots containing BLCH-Q). 
The contents of the AACH-Q shall be as shown in table 21.76. 

Table 21.76: Contents of AACH-Q 



Information element 


Length 


Type 


Value 


Remark 


AACH-Q mode 


1 


M 





Contents of ACCESS-ASSIGN PDU are present 


1 


Reserved element is present 


Contents of 

ACCESS-ASSIGN PDU 
(see note 1 ) 


14 


C 




This element contains the ACCESS-ASSIGN PDU, 
as defined in clause 21 .4.7.2, tables 21 .77 and 21 .78 


Reserved (see note 2) 


14 


C 




Reserved, value shall be set to all zeros 


NOTE 1 : The contents of ACCESS-ASSIGN PDU shall be present when the AACH-Q mode element is set to 0. 
NQTE 2: The reserved element shall be present when the AACH-Q mode element is set to 1 . 



The AACH-Q mode element indicates whether the ACCESS-ASSIGN PDU follows in the AACH-Q. The 
ACCESS-ASSIGN PDU is defined in clause 21.4.7.2. 

In the present document, the BS should set the AACH-Q mode element to 0. However, in future editions of the present 
document, the BS may set the AACH-Q mode element to 1 in some downlink slots. Therefore, if the AACH-Q mode 
element is set to 1, the MS shall discard the following 14 bits and shall regard the ACCESS-ASSIGN PDU as not 
having been received in that downlink slot. 



21.4.7.2 



ACCESS-ASSIGN 



The ACCESS-ASSIGN PDU is generated by the MAC and so shall not contain any TM-SDU from the layer above. 

On a 7I/4-DQPSK channel, or on a D8PSK channel, the ACCESS-ASSIGN PDU shall be sent by the BS on every 
downlink slot. It shall use the AACH logical channel, which is mapped onto the broadcast block (see clause 9). 

When sent on a QAM channel, the ACCESS-ASSIGN PDU shall use the AACH-Q logical channel. The AACH-Q shall 
be sent by the BS on every downlink slot of a QAM channel (except slots containing BLCH-Q). However the 
ACCESS-ASSIGN PDU is present in the AACH-Q only if the AACH-Q mode element is set to 0; see clause 21.4.7.1. 

NOTE 1: The phase modulation Access Assignment Channel AACH contains a single PDU: the 
ACCESS-ASSIGN PDU. 

The QAM Access Assignment Channel AACH-Q contains the 1-bit AACH-Q mode element, followed by 
either the ACCESS-ASSIGN PDU or a reserved element (see clause 21.4.7.1). 

The ACCESS-ASSIGN PDU shall be used to convey information about the downlink slot in which it appears and also 
the access rights for the corresponding (same-numbered) uplink slot. Its contents shall be dependent on whether it is 
being sent in frames 1 to 17 or in frame 18. The contents of this PDU shall be as shown in tables 21.77 and 21.78. 
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Table 21.77: ACCESS-ASSIGN PDU contents for frames 1 to 17 



Information element 


Length 


Type 


Value 


Remark 


Header 


2 


M 


OO2 


Downlink usage - common control 
Uplink access rights - common only 


OI2 


Downlink usage - defined by field 1 

Uplink access rights - common and assigned 


IO2 


Downlink usage - defined by field 1 
Uplink access rights - assigned only 


II2 


Downlink usage- defined by field 1 
Uplink access rights - defined by field 2 


Field 1 


6 


M 


See note 


Header OO2: Access field 1 
Header 01 2: Downlink usage marker 
Header IO2: Downlink usage marker 
Header 1 12: Downlink usage marker 


Field 2 


6 


M 


See note 


Header OO2: Access field 2 
Header 01 2: Access field 
Header IO2: Access field 
Header 1 12: Uplink usage marker 


NOTE: Content and values of the fields 1 and 2 depend on the Header values as defined in the Remarks column. 



Possible values for downlink usage marker in the field 1 : 

• Reserved (see note 2) UMr 00001 12 

• Common control 



Assigned control 

Unallocated 

Traffic 



UMc OOOOIO2 
UMa 000001 2 
UMx OOOOOO2 
UMt others (see note 3) 
Possible values for uplink usage marker in the field 2: 

• Unallocated UMx OOOOOO2 

• Traffic UMt others (see note 3) 

NOTE 2: UMr value is reserved for future standardization and is not used in the present document. 

NOTE 3: The values of the UMr, UMc, UMa and UMx are excluded. 

UMc, UMa and UMx are pre-set usage markers which shall not be assigned as traffic usage markers. UMt is the traffic 
usage marker, assigned in the MAC -RESOURCE PDU which allocated the channel. 

Access field 1 shall indicate the access restrictions for the first subslot of the corresponding uplink slot. Access field 2 
shall indicate the access restrictions for the second subslot of the corresponding uplink slot. Access field (with no 
following number) shall indicate the access restrictions for both subslots of the corresponding uplink slot. The definition 
of the access field contents is given in the access field element definition. 
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Table 21.78: ACCESS-ASSIGN PDU contents for frame 18 



Information element 


Length 


Type 


Value 


Remark 


Header 


2 


M 


OO2 


Uplink access rights: common only 


OI2 


Uplink access rights: common and assigned 


IO2 


Uplink access rights: assigned only 


II2 


Uplink access rights: common and assigned 


Field 1 


6 


M 


See note 


Header OO2: Access field 1 
Header 01 2: Access field 1 
Header IO2: Access field 1 
Header 11 2: Traffic usage marker (UMt) 


Field 2 


6 


M 


See note 


Header OO2: Access field 2 
Header 01 2: Access field 2 
Header IO2: Access field 2 
Header 1 1 2- Access field 


NOTE: Content and values of the fields 1 and 2 depend on the Header values as defined in the Remarks column. 



21 .4.8 MAC PDU structure for slot information cinannel 
21.4.8.1 QAM-SLOTINFO (uplink) 

This PDU is generated by the MAC and so shall not contain any TM-SDU from the layer above. This PDU shall be sent 
by the MS, within the SICH-Q/U, whenever it transmits a QAM slot or subslot by reserved access. 

NOTE: The QAM Uplink Slot Information Channel SICH-Q/U contains a single PDU: the uplink 
QAM-SLOTINFO PDU. 

This PDU indicates the format of the remainder of the uplink slot or subslot in which it appears. Its contents shall be as 
shown in table 21.79. 

Table 21.79: QAM-SLOTINFO (uplink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


Slot format 


5 


M 


OOOOO2 


4-QAMrate = 1/2 


00001 2 


16-QAMrate= 1/2 


0001 O2 


1 6-QAM rate = 1 


0001 I2 


64-QAMrate= 1/2 


001 OO2 


64-QAM rate = 2/3 


001012 


64-QAM rate = 1 


001 IO2 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 
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21.4.8.2 QAM-SLOTINFO (downlink) 

This PDU is generated by the MAC and so shall not contain any TM-SDU from the layer above. It shall be sent by the 
BS, within the SICH-Q/D, in every downlink slot on a QAM channel except slots containing BLCH-Q. 

NOTE: The QAM Downlink Slot Information Channel SICH-Q/D contains a single PDU: the downlink 
QAM-SLOTINFO PDU. 

This PDU indicates the format of the remainder of the downlink slot in which it appears (except the AACH-Q which 
always uses 4-QAM rate = 1/2). Its contents shall be as shown in table 21.80. 

Table 21.80: QAM-SLOTINFO (downlink) PDU contents 



Information element 


Length 


Type 


Value 


Remaric 


Slot format 


5 


M 


OOOOO2 


4-QAM rate = 1/2 


00001 2 


16-QAMrate= 1/2 


0001 O2 


1 6-QAM rate = 1 


0001 I2 


64-QAMrate= 1/2 


001 OO2 


64-QAM rate = 2/3 


001012 


64-QAM rate = 1 


001 IO2 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 



21.5 MAC elements 

Clauses 21.5.1 to 21.5.7 describe the information elements which are referred to in the MAC PDU descriptions. The 
contents of those information elements shall as defined in tables 21.81 to 21.91. 

21.5.1 Access field 

Table 21.81 : Access field information element contents 



Information element 


Length 


Type 


Value 


Remark 


Access code 


2 


M 


OO2 


Access code A 


OI2 


Access code B 


IO2 


Access code C 


II2 


Access code D 


Base frame-length 


4 


M 


OOOO2 


Reserved subslot, see note 1 


0001 2 


CLCH(-Q) subslot, see notes 1 and 2 


001 O2 


Ongoing frame 


0011 2 


1 subslot 


01002 


2 subslots 


01012 


3 subslots 


01102 


4 subslots 


01112 


5 subslots 


10002 


6 subslots 


1001 2 


8 subslots 


10102 


10 subslots 


10112 


12 subslots 


11002 


16 subslots 


11012 


20 subslots 


11102 


24 subslots 


11112 


32 subslots 


NOTE 1 : For these values access code has no meaning. 

NOTE 2: CLCH and CLCH-Q are permitted only in subslot 1 as specified in clauses 9.5.1, 9.5.1a and 9.5.6. 
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21.5.2 Channel allocation 



Table 21.82: Channel allocation information element contents 



Information element 


Length 


Type 


Value 


Remark 


Allocation type 


2 


M 


OO2 


Replace current channel with specified channel 


OI2 


Additional channel allocation 


IO2 


Quit current channel and go to specified channel 


II2 


Replace current channel with specified channel plus 
carrier specific signalling channel in slot 1 


Timeslot assigned 


4 


M 


OOOO2 


Go to appropriate common control channel (I\/1CCH 
or common SCCH) 


0001 2 


Timeslot number 4 


001 O2 


Timeslot bit map 


etc. 


etc. 


IIIO2 


Timeslot bit map 


IIII2 


All four timeslots 


Up/downlink assigned 


2 


M 


OO2 


Augmented channel allocation (see note 1) 


OI2 


Downlink only 


IO2 


Uplink only 


II2 


Both uplink and downlink 


CLCH(-Q) permission 


1 


M 





No immediate CLCH(-Q) permission 


1 


Immediate CLCH(-Q) permission 


Cell change flag 


1 


M 





No cell change 


1 


Cell change 


Carrier number 


12 


M 




Carrier frequency number 


Extended carrier numbering flag 


1 


M 





No extended carrier numbering 


1 


Extended carrier numbering 


Frequency band (see note 2) 


4 


C 




Provision for different frequency bands 


Offset (see note 2) 


2 


C 


002 


kHz offset 


012 


+6,25 kHz offset 


102 


-6,25 kHz offset 


112 


+12,5 kHz offset 


Duplex spacing (see note 2) 


3 


C 




Provision for different duplex spacing 


Reverse operation (see note 2) 


1 


C 





Normal 


1 


Reverse 


Monitoring pattern (see clause 9) 


2 


M 


002 


No monitoring pattern 


012 


One monitoring pattern 


102 


Two monitoring patterns 


112 


Three monitoring patterns 


Frame 1 8 monitoring pattern 
(see note 3) 


2 


C 


002 


No monitoring pattern 


012 


One monitoring pattern 


102 


Two monitoring patterns 


112 


Three monitoring patterns 


Up/downlink assigned for 
augmented channel allocation 
(see note 4) 


2 


C 


002 


Reserved (see note 5) 


012 


Downlink only 


102 


Uplink only 


112 


Both uplink and downlink 


Bandwidth of allocated channel 
(see notes 4 and 6) 


3 


C 


0002 


25 kHz 


0012 


50 kHz 


01 O2 


100 kHz 


0112 


150 kHz 


1002 


Reserved 


etc. 


etc. 


III2 


Reserved 
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Information element 


Length 


Type 


Value 


Remark 


Modulation mode of allocated 
channel (see note 4) 


3 


C 


OOO2 


TT/4-DQPSK 


OOI2 


D8PSK 


01 O2 


QAM 


0112 


Reserved 


etc. 


etc. 


III2 


Reserved 


Maximum uplink QAM modulation 
level (see notes 7 and 8) 


3 


C 


OOO2 


Reserved 


OOI2 


16-QAM 


01 O2 


64-QAM 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 


Reserved (see note 9) 


3 


c 




Reserved, value shall be set to OOO2 


Conforming channel status 
(see note 4) 


3 


c 


OOO2 


Conforming channel (therefore concentric) 


OOI2 


Non-conforming channel: concentric 


01 O2 


Non-conforming channel: sectored 


OII2 


Reserved 


etc. 


etc. 


III2 


Reserved 


BS link imbalance (see note 4) 


4 


c 




See "BS link imbalance" information element 
definition 


BS transmit power relative to main 
carrier (see note 4) 


5 


c 




See "BS transmit power relative to main carrier" 
information element definition 


Napping status (see note 4) 


2 


c 


OO2 


Napping is not permitted on the allocated channel 


OI2 


Napping information is included 


IO2 


MS may use current napping information on the 
allocated channel 


II2 


Reserved 


Napping information (see note 10) 


11 


c 




See "napping information" information element 
definition 


Reserved (see note 4) 


4 


c 




Reserved, value shall be set to OOOO2 


First conditional element flag 
(see note 4) 


1 


c 





First conditional element not present 


1 


First conditional element present 


First conditional element 
(see note 1 1 ) 


16 


c 




Reserved, value shall be set to all zeros 


Second conditional element flag 
(see note 4) 


1 


c 





Second conditional element not present 


1 


Second conditional element present 


Second conditional element 
(see note 1 2) 


16 


c 




Reserved, value shall be set to all zeros 


Further augmentation flag 
(see note 4) 


1 


c 





No further augmentation of channel allocation 


1 


Further augmentation of channel allocation 
(see note 13) 



£75/ 



635 ETSI TS 300 392-2 V3.3.1 (2008-1 0) 



Information element Length Type Value Remark 



NOTE 1 : If an MS that does not support augmented channel allocations receives a channel allocation with the 

up/downlink assigned element set to OO2, it shall discard the channel allocation and any TM-SDU carried in 

the IVIAC-RESOURCE or MAC-END PDU that contained the channel allocation. 
NOTE 2: This element shall be present only in the case of extended carrier numbering i.e. extended carrier numbering 

flag set to 1 . 
NOTE 3: This element shall be present only in the case that no monitoring pattern is assigned i.e. monitoring pattern 

element set to OO2. 
NOTE 4: This element shall be present only for an augmented channel allocation i.e. up/downlink assigned element 

set to OO2. 
NOTE 5: If the MS receives a channel allocation with the up/downlink assigned for augmented channel allocation 

element set to OO2, it shall discard the channel allocation and any TM-SDU carried in the MAC-RESOURCE 

or MAC-END PDU that contained the channel allocation. 
NOTE 6: This element shall be set to OOO2 when allocating a tt/4-DOPSK channel or a D8PSK channel. 
NOTE 7: This element shall be present only for an augmented channel allocation allocating a QAM channel i.e. 

up/downlink assigned element set to OO2 and modulation mode of allocated channel element set to 01 O2. 
NOTE 8: If the MS does not understand the value of this element, it shall regard the value as indicating the maximum 

QAM modulation level supported by that MS. 
NOTE 9: This element shall be present only for an augmented channel allocation not allocating a QAM channel i.e. 

up/downlink assigned element set to OO2 and modulation mode of allocated channel element not set to 01 O2. 
NOTE 10: This element shall be present only for an augmented channel allocation with napping information included 

i.e. up/downlink assigned element set to OO2 and napping status element set to 01 2. 
NOTE 1 1 : This element shall be present only for an augmented channel allocation with the first conditional element flag 

indicating that the first conditional element is present i.e. up/downlink assigned element set to OO2 and first 

conditional element flag set to 1 . 
NOTE 12: This element shall be present only for an augmented channel allocation with the second conditional element 

flag indicating that the second conditional element is present i.e. up/downlink assigned element set to OO2 

and second conditional element flag set to 1 . 
NOTE 1 3: The further augmentation flag shall be set to in the present document. If the MS receives a channel 

allocation with the further augmentation flag set to 1 , it shall discard the channel allocation and any TM-SDU 

carried in the MAC-RESOURCE or MAC-END PDU that contained the channel allocation. 



The CLCH(-Q) permission field shall indicate to the MS whether the first sub-slot on the allocated channel shall be 
available for linearization purposes: CLCH on a 7i/4-DQPSK or D8PSK channel, or CLCH-Q on a QAM channel. The 
MS need not examine the ACCESS-ASSIGN PDU in the AACH or AACH-Q in order to use CLCH or CLCH-Q if 
permission is given in the channel allocation field. 

The carrier frequency shall be defined by the following elements: 

carrier number; 

extended carrier numbering flag; 

frequency band; 

offset; 

duplex spacing; 

reverse operation; 

bandwidth of allocated channel. 
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The extended numbering flag indicates whether the carrier frequency specification includes the frequency band, offset, 
duplex spacing and reverse operation fields. If this field indicates no extended numbering, then the MS shall assume the 
same frequency band, offset, duplex spacing and reverse operation values as contained in the SYSINFO or SYSINFO-Q 
PDU. If the bandwidth of allocated channel field is not included, then the MS shall assume that the bandwidth is 
25 kHz. The actual carrier frequency shall then be calculated using a similar method to that defined for the main carrier 
frequency calculation in the SYSINFO PDU description but with an additional term to allow for bandwidths greater 
than 25 kHz. The carrier frequency shall be as defined by the following equations: 



• 



• 



downlink carrier frequency = base frequency + (carrier number x 25 kHz) + offset kHz 

+ ( (bandwidth of allocated channel / 2) - 12,5 ) kHz 

normal operation: 

uplink carrier frequency = downlink carrier frequency - duplex spacing 
reverse operation: 

uplink carrier frequency = downlink carrier frequency + duplex spacing. 

The mappings of the frequency band field values to actual base frequencies and the duplex spacing field values to actual 
duplex frequency spacing are defined in TS 100 392-15 [18]. 

NOTE: For bandwidths greater than 25 kHz, the carrier number refers to the centre frequency of the lowest 

25 kHz comprising the allocated channel. The final term (relating to the bandwidth) in the equation for 
the downlink carrier frequency then generates the centre frequency of the allocated channel. 

The monitoring pattern field applies to a transmitting MS on an assigned channel and it indicates which downlink slots 
shall be monitored while transmitting traffic. If one monitoring pattern is assigned, monitoring pattern number one as 
defined in clause 9 shall be used. If two monitoring patterns are assigned, monitoring pattern numbers one and two as 
defined in clause 9 shall be used. If three monitoring patterns are assigned, monitoring pattern numbers one, two and 
three as defined in clause 9 shall be used. 

If no monitoring pattern is assigned, then the frame 18 monitoring pattern field shall be included to indicate which 
monitoring patterns shall be followed for frame 18. One, two or three monitoring patterns can be assigned for frame 18 
in the same way as described before. So, for example, if one monitoring pattern is assigned, the MS shall monitor 
frame 18 if Multiframe Number mod 3 = 0; if two monitoring patterns are assigned, the MS shall monitor frame 18 if 
Multiframe Number mod 3 = or 2. 

Values 01 2, IO2, and II2 in the up/downlink assigned field indicate whether either or both directions on the allocated 
channel have been assigned exclusively for the usage required by the MS. Value OO2 in the up/downlink assigned field 
indicates that this is an augmented channel allocation. In this case the following conditional fields shall be included: 

up/downlink assigned for augmented channel allocation; 

bandwidth of the allocated channel; 

modulation mode of the allocated channel; 

the maximum uplink QAM modulation level, or a 3-bit reserved element; 

conforming channel status of the allocated channel; 

BS link imbalance on the allocated channel (see clause 21.5.2a); 

BS transmit power on the allocated channel relative to the main carrier (see clause 21.5.2b); 

napping status on the allocated channel and, optionally, napping information (see clause 21.5.2c); 

a 4-bit reserved element; 

a flag indicating whether a first 16-bit conditional element is present, and the conditional element if 
appropriate; 
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• a flag indicating whether a second 16-bit conditional element is present, and the conditional element if 
appropriate; and 

• a flag indicating further augmentation of the channel allocation (allowing for future further extension). 

If the channel allocation is not augmented, the MS shall assume that the allocated channel is a 25 kHz 3i/4-DQPSK 
conforming channel, that the BS transmit power on the allocated channel relative to the main carrier is dB and that use 
of the napping procedure is not permitted on the allocated channel. 

21.5.2a BS link imbalance 

Table 21.83: "BS link imbalance" information element contents 



Information element 


Length 


Type 


Value 


Remark 


BS link imbalance 


4 


M 


OOOO2 


No information 


OOOI2 


Reserved 


001 O2 


Reserved 


OOII2 


-12,5 dB 


OIOO2 


-lOdB 


OIOI2 


-7,5 dB 


011 O2 


-5dB 


01112 


-2,5 dB 


10002 


OdB 


10012 


2,5 dB 


10102 


5dB 


10112 


7,5 dB 


11002 


lOdB 


11012 


12,5dB 


11102 


Reserved 


11112 


Reserved 



The BS shall set the "BS link imbalance" information element to: 

( BS transmit power - MS_TXPWR_MAX_CELL ) 

+ Gain in the BS transmitter feeder and antenna 

- Gain in the BS receiver feeder and antenna 

H- ( BS static receive sensitivity - MS static reference sensitivity ), 

where all parameters are those applicable to the allocated channel and the receive sensitivities are for the lowest 
modulation level supported by the channel (i.e. 7i/4-DQPSK or 4-QAM). 

The MS may use the BS link imbalance, together with an MS correction factor (see note 1), to estimate the uplink 
performance from measurements of the downlink channel; this information may be a criterion in the MS's link 
adaptation procedures for choice of the current appropriate bit rate on a D8PSK or QAM channel; see clause 23.4.9. 

NOTE 1: The MS correction factor should allow for the MS's actual transmit power, its actual static sensitivity and 
any receive/transmit imbalance in the performance of its antenna. For example, the MS might choose to 
use the following or equivalent correction factor: 

( MS_TXPWR_MAX_CELL - MS actual transmit power ) 

- Gain in the MS transmitter feeder and antenna 

+ Gain in the MS receiver feeder and antenna 

+ ( MS static reference sensitivity - MS actual static sensitivity ). 

NOTE 2: In the above expressions for the BS link imbalance and the MS correction factor, the "gain in the receiver 
feeder and antenna" is assumed to include any diversity gain. 
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21 .5.2b BS transmit power relative to main carrier 

Table 21.84: "BS transmit power relative to main carrier" information element contents 



Information element 


Length 


Type 


Value 


Remark 


BS transmit power relative to 
main carrier 


5 


M 


OOOOO2 


Reserved 


etc. 


etc. 


001 OO2 


Reserved 


OOIOI2 


-22 dB 


001 IO2 


-20 dB 


etc. 


etc. 


IOOOO2 


OdB 


etc. 


etc. 


IIOIO2 


20 dB 


IIOII2 


22 dB (2 dB steps) 


IIIOO2 


Reserved 


etc. 


etc. 


IIIII2 


Reserved 



The value of the BS transmit power relative to main carrier element shall include the BS relative antenna gains; i.e. it is 
the BS Effective Radiated Power (ERP) into the allocated channel relative to the BS ERF of the main carrier. 



21.5.2c Napping information 



Table 21.85: "Napping information" information element contents 



Information element 


Length 


Type 


Value 


Remark 


Napping reception timeslots 


4 


M 


OOOO2 


Reserved 


OOOI2 


Timeslot number 4 


001 O2 


Timeslot bit map 


etc. 


etc. 


IIIO2 


Timeslot bit map 


IIII2 


All four timeslots 


Napping reception frames 


3 


M 


OOO2 


AIITDMA frames 


001 2 


Odd-numbered TDIVIA frames 

i.e. frames 1 , 3, 5, 7, 9, 1 1 , 1 3, 1 5 and 1 7 


01 O2 


Even-numbered TDIVIA frames 

i.e. frames 2, 4, 6, 8, 10, 12, 14, 16 and 18 


OII2 


Frames 1, 4, 7, 10, 13 and 16 


IOO2 


Frames 2, 5, 8, 11, 14 and 17 


IOI2 


Frames 3, 6, 9, 12, 15 and 18 


IIO2 


Reserved 


III2 


Reserved 


Napping timer T.226 


3 


M 


OOO2 


6 TDIVIA frames 


001 2 


9 TD MA frames 


01 O2 


1 2 TDMA frames 


0112 


1 8 TD MA frames 


1002 


27 TDMA frames 


1012 


36 TDMA frames 


1102 


54 TDMA frames 


1112 


Reserved 


Reduced reception in 
frame 1 8 flag 


1 


M 





Use of reduced reception in frame 18 is not permitted 


1 


Use of reduced reception in frame 18 is permitted 
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21.5.3 Power control 



Table 21.86: Power control information element contents 



Information element 


Length 


Type 


Value 


Remark 


Power control 


4 


M 


OOOO2 


No change in power 


0001 2 


Increase power by 1 step 


001 O2 


Increase power by 2 steps 


0011 2 


Increase power by 3 steps 


01002 


Increase power by 4 steps 


01012 


Increase power by 5 steps 


01102 


Increase power by 6 steps 


01112 


Maximum path delay exceeded 


10002 


Revert to open loop power control 


1001 2 


Decrease power by 1 step 


10102 


Decrease power by 2 steps 


10112 


Decrease power by 3 steps 


11002 


Decrease power by 4 steps 


11012 


Decrease power by 5 steps 


11102 


Decrease power by 6 steps 


11112 


Radio uplink failure 



The power control step size is nominally 5 dB as defined in clause 6 except for power classes nL, where n is 1 to 4 
(refer to the nominal power of MS transmitters defined in clause 6.4.1.2). For those power classes the step between the 
nominal power and the first lower power level is 2,5 db so that the nominal MS power control levels defined in 
clause 6.4.1.2 are applicable except for the highest power. The power shall not be decreased below the minimum power 
control level of 15 dBm or increased above the nominal power of that MS class. 



21.5.4 Reservation requirement 



Table 21.87: Reservation requirement information element contents in 
MAC-ACCESS, MAC-END-HU, MAC-DATA and uplink MAC-END PDUs 



Information element 


Length 


Type 


Value 


Remark 


Reservation requirement 


4 


M 


OOOO2 


1 subslot required 


0001 2 


1 slot required 


001 O2 


2 slots required 


0011 2 


3 slots required 


01002 


4 slots required 


01012 


5 slots required 


01102 


6 slots required 


01112 


8 slots required 


10002 


10 slots required 


1001 2 


13 slots required 


10102 


17 slots required 


10112 


24 slots required 


11002 


34 slots required 


11012 


51 slots required 


11102 


68 slots required 


11112 


IVIore than 68 slots required 



£75/ 



640 



ETSI TS 300 392-2 V3.3.1 (2008-10) 



Table 21.88: Reservation requirement information element contents in MAC-U-BLCK PDU 



Information element 


Length 


Type 


Value 


Remark 


Reservation requirement 


4 


M 


OOOOg 


1 subslot required 


0001 2 


1 slot required 


001 O2 


2 slots required 


0011 2 


3 slots required 


01002 


4 slots required 


01012 


5 slots required 


01102 


6 slots required 


01112 


8 slots required 


10002 


10 slots required 


1001 2 


13 slots required 


10102 


17 slots required 


10112 


24 slots required 


11002 


34 slots required 


11012 


51 slots required 


11102 


68 or more slots required 


11112 


No reservation requirement 



21.5.5 TS COMMON FRAMES 



Table 21 .89: TS COIVIMON FRAMES information element contents 



Information element 


Length 


Type 


Value 


Remark 


Frame 1 




M 





Not a common frame 


1 


Common frame 


Frame 2 




M 





Not a common frame 


1 


Common frame 


etc. 


etc. 


etc. 





etc. 


1 


etc. 


Frame 18 




M 





Not a common frame 


1 


Common frame 


Reserved 




M 





Default value 


1 


Not used in the present document 


Reserved 




M 





Default value 


1 


Not used in the present document 
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21 .5.6 Basic slot granting 



Table 21.90: Basic slot granting information element contents 



Information element 


Length 


Type 


Value 


Remark 


Capacity Allocation 


4 


M 


OOOO2 


First subslot allocated 


OOOI2 


1 slot allocated 


001 O2 


2 slots allocated 


OOII2 


3 slots allocated 


OIOO2 


4 slots allocated 


OIOI2 


5 slots allocated 


OIIO2 


6 slots allocated 


OIII2 


8 slots allocated 


IOOO2 


1 slots allocated 


IOOI2 


1 3 slots allocated 


IOIO2 


1 7 slots allocated 


IOII2 


24 slots allocated 


IIOO2 


34 slots allocated 


IIOI2 


51 slots allocated 


IIIO2 


68 slots allocated 


IIII2 


Second subslot allocated 


Granting delay (see note) 


4 


M 


OOOO2 


Capacity allocation at next opportunity 


OOOI2 


Number of opportunities delay to capacity allocation 


etc. 


etc. 


IIOI2 


Number of opportunities delay to capacity allocation 


IIIO2 


Allocation starts at first opportunity in frame 18 


IIII2 


Wait for another slot granting message 


NOTE: For basic slot granting, and for the first basic slot granting element in a multiple slot grant, the granting delay 
is counted from the slot containing the slot grant. For multiple slot granting, the granting delay in the second 
and subsequent basic slot granting elements (either explicitly included or implicit) is counted from the end of 
the grant defined by the previous basic slot granting element (either explicitly included or implicit). 



21.5.7 Multiple slot granting 



Table 21.91 : Multiple slot granting information element contents 



Information element 


Length 


Type 


Value 


Remark 


Number of slot granting sets 
(see note 1 ) 


3 


M 


OOO2 


Reserved 


001 2 


1 slot granting set 


etc. 


etc. 


III2 


7 slot granting sets 


Basic slot granting element 
(see note 2) 


8 


C 




See basic slot granting information element definition 


Implicit repeat count 
(see note 2) 


4 


C 


OOOO2 


No implicit repetition of basic slot granting element 


OOOI2 


1 implicit repetition of basic slot granting element 


etc. 


etc. 


IIII2 


15 implicit repetitions of basic slot granting element 


NOTE 1 : The "number of slot granting sets" element indicates the number of slot granting sets that follow in the PDU. 
Each slot granting set comprises two information elements i.e. "basic slot granting element" and "implicit 
repeat count". The information elements in each repeated set shall be in the order specified. For example, if 
the "number of slot granting sets" element is set to 01 O2, it is followed by: first basic slot granting element, 
implicit repeat count for first basic slot granting element, second basic slot granting element, implicit repeat 
count for second basic slot granting element. 

NOTE 2: Shall be repeated as a set as indicated by the "number of slot granting sets" element. 
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21 .6 Units used in length indication 



The "length indication" element in some TMA-SAP MAC PDUs indicates the length of the MAC PDU in units of: 

• Yi and Zi octets, for a PDU sent in a subslot (i.e. MAC-ACCESS or MAC-END-HU); and 

• Y2 and Z2 octets, for a PDU sent in a slot (i.e. MAC-DATA, MAC-RESOURCE or MAC-END); 

where the values of Yj, Zj, Y2 and Z2 depend on the bandwidth, modulation and coding rate with which the PDU is 
sent. The values of Yj, Zj, Y2 and Z2 are given in table 21.92 for each combination. 

Table 21.92: Value of Yi, Zi, Y2 and Z2 in TMA-SAP MAC PDUs 



Modulation and QAM coding 

rate and bandwidth with which 

PDU is sent 


Yi 

(PDU sent in 

a subslot) 


Zi 

(PDU sent in 

a subslot) 


Y2 

(PDU sent in 

a slot) 


Z2 

(PDU sent in 

a slot) 


TT/4-DQPSK 


1 


1 


1 


1 


TT/8-D8PSK 


1 


2 


1 


2 


4-QAM rate=1/2, 25 kHz 


1 


1 


1 


1 


16-QAM rate=1/2, 25 kHz 


1 


2 


1 


2 


16-QAM rate=1, 25 kHz 


2 


3 


2 


3 


64-QAM rate=1/2, 25 kHz 


1 


2 


1 


2 


64-QAM rate=2/3, 25 kHz 


2 


3 


2 


3 


64-QAM rate=1, 25 kHz 


2 


4 


2 


4 


4-QAM rate=1/2, 50 kHz 


1 


2 


1 


2 


16-QAM rate=1/2, 50 kHz 


2 


3 


2 


3 


16-QAM rate=1, 50 kHz 


2 


6 


2 


5 


64-QAM rate=1/2, 50 kHz 


2 


4 


2 


4 


64-QAM rate=2/3, 50 kHz 


2 


6 


2 


5 


64-QAM rate=1, 50 kHz 


2 


8 


2 


8 


4-QAM rate=1/2, 100 kHz 


2 


3 


2 


3 


16-QAM rate=1/2, 100 kHz 


2 


6 


2 


5 


16-QAM rate=1, 100 kHz 


2 


11 


2 


8 


64-QAM rate=1/2, 100 kHz 


2 


9 


2 


8 


64-QAM rate=2/3, 100 kHz 


2 


11 


2 


8 


64-QAM rate=1, 100 kHz 


2 


17 


2 


8 


4-QAM rate=1/2, 150 kHz 


2 


4 


2 


4 


16-QAM rate=1/2, 150 kHz 


2 


9 


2 


8 


16-QAM rate=1, 150 kHz 


2 


17 


2 


8 


64-QAM rate=1/2, 150 kHz 


2 


13 


2 


8 


64-QAM rate=2/3, 150 kHz 


2 


17 


2 


8 


64-QAM rate=1, 150 kHz 


2 


22 


2 


8 



NOTE: When an MS sends a random access request on a QAM channel, it uses logical channel SCH-Q/RA in a 
subslot. This logical channel always uses 4-QAM modulation with rate = 1/2 in a 25 kHz bandwidth 
(irrespective of the bandwidth of the QAM channel). Therefore Yi = Zj = 1 applies. 
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22 LLC protocol 



This clause is intended to be read together with the MAC protocol, clause 23. This clause describes the LLC sub-layer 
framing functions for the V+D air interface. These sub-layer functions are closely integrated with the MAC sub-layer 
and together the MAC and LLC form the air interface layer 2, also called DLL. An overview of the DLL architecture 
can be found in clause 19. 

22.1 Overview of LLC 

See EN 300 392-1 [6], clause 6 for general architecture and functional description. See clause 19 for DLL architecture. 
See clause 20 for service description and SAPs. See clause 21 for PDU description. 

The LLC procedures defined in the present document are applicable to the MS unless indicated to be valid for the BS. 
The LLC procedures used in the BS shall be compatible with the procedures described in the present document. 

NOTE: Throughout clause 22 the word "shall" is used with service primitives for traceability reasons in the 
protocol model, but the primitives are not testable. 



22.1.1 LLC protocol 



LLC protocol for TETRA contains two entities, basic link and advanced link, both accessible via the same SAP 
TLA-SAP. Both the data links offer two different services, i.e. unacknowledged and acknowledged information transfer 
mechanisms. The basic link is available whenever the MS is synchronized to a BS. The advanced link provides a better 
quality of service than the basic link and uses a connection on demand. There are two variants of advanced link: the 
original advanced link and the extended advanced link. 

The basic link offers an option for extended Frame Check Sequence (FCS) to minimize the number of undetected 
erroneous messages. The same frame check sequence is always used on the original advanced link and may optionally 
be used on the extended advanced link. 

The MS LLC may support up to four advanced links per service, numbered from one to four. It may use either: 

• one original advanced link per service plus up to three extended advanced links per service; or 

• up to four extended advanced links per service. 

The various link services will be discriminated locally by a different link identifier. Link identifiers in the peer entity 
may be independent of these local identifiers. In the LLC itself, the distinct PDU types shall differentiate both between 
a basic and an advanced link and unacknowledged and acknowledged service (see clause 21). For a certain advanced 
link number, there can exist one acknowledged service or one unacknowledged service or both. Unacknowledged and 
acknowledged services are set up and disconnected independently of each other. If they coexist on the same advanced 
link number, they may use the same physical allocation (same timeslot or timeslots), in which case there is only one 
basic link associated with both the advanced link services. 

If an MS LLC supports more than one advanced link per service, those advanced links may share the same physical 
allocation (same timeslot or timeslots). So the MS LLC may support up to four advanced links per service on a single 
physical allocation, in which case there is only one basic link associated with those advanced links. 

Alternatively, if the MS is capable of supporting more than one physical allocation concurrently, the MS LLC may have 
advanced link(s) on each of the physical allocations provided that the total number of advanced links is not more than 
four per service. 

NOTE: The above three paragraphs refer to the services available for one address. ITSIs and GTSIs in an MS are 
independent of each other and LLC services recognize addresses to allow concurrent basic or advanced 
link services. The present document does not describe how addresses affect the LLC implementation. 

There is one basic link per each advanced link (or per set of advanced links if multiple advanced links share the same 
physical allocation) and each circuit mode service, when an ACCH is available. The number of timeslots each basic link 
may use is the same as the number of timeslots of the corresponding advanced link(s) or circuit mode service. 
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The transfer mode of an LLC link is independent of the modes of the other LLC links forming a network layer 
connection. As an example, a point-to-multipoint call from an MS to multiple MSs may use an advanced LLC link from 
the sending MS to the BS and the unacknowledged basic LLC link from the BS to the receiving MSs. 

This LLC protocol for TETRA operates using PDUs. The PDUs are described in clause 2L The basic link LLC PDU 
sizes are independent of the MAC layer block sizes, because the MAC can fragment an LLC PDU if needed. For the 
advanced link: 



• 



• 



when on a 7i/4-DQPSK or D8PSK channel, the advanced link LLC protocol is constrained by the segment 
sizes matching the available room in MAC blocks; therefore, on a D8PSK channel, segments may be of 
different sizes, depending on whether they are cut to be sent using 7i/4-DQPSK or 71/8-D8PSK modulation for 
the first transmission of that segment; 

when on a 25 kHz or 50 kHz QAM channel, the segment size is normally determined by the available space in 
a 4-QAM rate = V2 full-slot MAC block at the current bandwidth; when on a 100 kHz or 150 kHz QAM 
channel, the segment size is normally determined by the available space in half of a 4-QAM rate = V2 full-slot 
MAC block at the current bandwidth. The first and last segment of a TL-SDU may be of different size. 

In addition to the basic link and advanced link entities, the LLC may contain a control entity (LLC-CTRL). This entity 
sends and receives layer 2 signalling PDUs, using unacknowledged information transfer mechanisms. Layer 2 
signalling PDUs carry various types of general signalling information relating to layer 2 functions. The layer 2 
functions may be either LLC or MAC functions. However, for the purposes of the data exchange mechanisms, the 
layer 2 signalling PDUs are treated as LLC PDUs. In cases where the layer 2 signalling relates to a MAC function, the 
LLC provides the information transfer service to the MAC via the TLB-SAP. 

The data link operation may use the knowledge of the multiframe structure for transmission optimization. 

22.1 .2 Communication routes of tine LLC model 

Figure 22.1 shows relations of the MS LLC layer protocols in the TETRA protocol stack. The MLE selects service and 
signal route by selecting the link identifier at the TLA-SAP. There is also an LLC flow control provided between LLC 
peer entities on the advanced link. The flow control is accessible to the LLC service user via a MLE-LLC control route. 
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TL_DATA_confirm, 
TL_DATA_indication, 
TL_REPORT_indication, 
TL UNITDATA indication; 



TLA SAP route bl 



TL_DATA_request, 
TL_DATA_response, 
TL_CANCEL_request, 
TL_UNITDATA_request; 



/\ 



N/ 



TL_CONNECT_indication, 

TL_CONNECT_confirm, 

TL_DATA_confirm, 

TL_DATA_indication, 

TL_DISCONNECT_indication, 

TL_DISCONNECT_confirm, 

TL_RECEIVE_indication, 

TL_RECONNECT_confirm, 

TL_REPORT_indication, 

TL_UNITDATA_indication; 

TLA_SAP_route_al 

TL_CANCEL_request, 

TL_CONNECT_request, 

TL_CONNECT_response, 

TL_DATA_request, 

TL_DISCONNECT_request, 

TL_RECONNECT_request, 

TL_UNITDATA_request; 



/\ 



N/ 



Control_route_ 
MLE LLC 



FLOW_NOT_READY, 
FLOW_READY; 



N/ 



LLC MS 



TLE_CANCEL_request, 
TLE_UNITDATA_request; 

TLE_SAP_route 

TLE_REPORT_indication, 
TLE_UNITDATA_indication 



/^ 



/\ 



\/ 



\/ 



IVIAC_READY, 

TI\/IA_REPORT_indication, 

TIVlA_UNITDATA_indication; 

TMA_SAP_route 

DATA_IN_BUFFER, 
TIVIA_CANCEL_request, 
TIVIA_UN ITDATA_request; 



MAC MS 



-^ 



Radio_path 



:: 







Figure 22.1 : LLC relations 
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TLE_CANCEL_ 
request, 

TLE_UNITDATA_ 
request; 



TLE_SAP_ 
route 



TLE_UNITDATA_ 
indication; 



MAC_READY, 

TMA_REPORTJ ndication, 

L2_SCHEDULE_SYNC, 

L2_LI NK_FEEDBACK_CDNTROL, 

L2_LI NK_FEEDBACK_I NFO; 

TX_RX_ 
route L2 



DATA_IN_BUFFER, 
L2_DATA_PRI0RITY, 
L2_LI NK_FEEDBACK_I NFO, 

L2_LINK_FEEDBACK_INFO_ 
AND_RESI DUAL_DATA_ 
PRIORITY; 



TL_DATA_ 

confirm, 

TL_DATA_ 

indication, 

TL_REPORT_ 

indication, 

TL_UNITDATA_ 

indication; 



■n.A_SAP_ 
route_bl 



TL_DATA_ 
request. 



TL_CANCEL_ 
request, 

TL_UNITDATA_ 
request; 



BL_ACK, 

BL_DATA, 

BL_ADATA, 

BL_UDATA, 

MAC_READY, 

TMA_REPORT_ 

indication; 



7X_RX_ 
route bl 



BL_ACK, 

BL_DATA, 

BL_ADATA, 

BL_UDATA, 

DATA_IN_BUFFER; 



TL_DATA_ 
confirm, 
TL_REPORT_ 
indication; 



TL_DATA_ 

request, 

TL_CANCEL_ 

request, 

TL_UNITDATA_ 

request; 



TL_CONNECT_ 

indication, 

TL_CONNECT_ 

confirm, 

TL_DISCONNECT_ 

indication, 

TL_RECONNECT_ 

confirm, 

TL_REPORT_ 

indication; 

Route_ 
alrnain 

TL_CONNECT_ 

request, 

TL_CONNECT_ 



TL_DISCONNECT_ 
request, 

TL_RECONNECT_ 
request; 



Control_route_ 
MLE_LLC 

rFLOW_NOT_READY, 
FLOW_READY; 



Control_ 
routeal 

Start_TX 
pop_TXJ 



AL(_X)_ACK, 

AL(_X)_RNR, 

MAC_READY, 

TMA_REPORT_ 

indication; 



ALLX)_DATA, 

AL(_X)_DATA_AR, 

AL(_X)_FINAL, 

AL(_X)_FINAL_AR, 

DATA_IN_BUFFER; 



AL_SETUP, 

AL_DISC, 

AL_RECONNECT; 



Mainrouteal 



AL_SETUP, 
AL_DISC, 
AL_RECONNECT, 
DATA_IN_BUFFER; 



ControL 
route_al 

Start_RX 
pop_RXJ 



&: 



DATA_indication 
RECEIVEJndication^ 



AL(_X)_DATA, 

ALLX)_DATA_AR, 

ALLX)_FINAL, 

ALLX)_FINAL_AR, 

MAC_READY; 



AL(_X)_ACK 
AL(_X)_RNR 
DATA_IN_ 
BUFFER; 



FrL.UNITDATAn 
|_indication; _| 

Route 

al UNACK 



[allxj.udata"] 
|_allx)_ufinalJ 

UNACK_ 
route al 



MAC_READY (size), 
TMA_REPORT_indication, 
TMA_UNITDATA_indication ; 

TTWA SAP route 

DATA_IN_BUFFER (size, 

priority), 

TMA_UNITDATA_request; 



Figure 22.2: LLC protocol structure 

Figure 22.2 shows the internal structure of the LLC presenting the basic and the advanced links, layer 2 signalling and 
layer composition of various processes. 

The basic link protocol uses the following routes: 

• the TLA-SAP route bl corresponds to the TLA-SAP; 

• the TX-RX route bl corresponds to TMA-SAP showing LLC PDUs. 
The advanced link protocol uses the following routes: 

• the Route al main corresponds to the TLA-SAP for the connection set-up, reconnection and disconnection; 

• the Route al TX corresponds to the TLA-SAP for acknowledged data transmission; 

• the Route al RX corresponds to the TLA-SAP for acknowledged data reception; 

• the Control Route MLE-LLC corresponds to the TLA-SAP for flow control purposes; 

• the Main route al corresponds to TMA-SAP and carries LLC PDUs for connection set-up, reconnection and 
disconnection; 
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• the TX route al corresponds to TMA-SAP and carries LLC PDUs and control signals, which are used in 
acknowledged data transmission; 

• the RX route al corresponds to TMA-SAP and carries LLC PDUs and control signals, which are used in 
acknowledged data reception; 

• the Route al UNACK corresponds to TLA-SAP for unacknowledged service; 

• the UNACK route al corresponds to TMA-SAP and carries LLC unacknowledged service PDUs; 

• the Control route al carries local control of the advanced links. 
The layer 2 signalling protocol uses the following routes: 

• the TLE-SAP route corresponds to the TLE-SAP; 

• the TX-RX route L2 corresponds to TMA-SAP and carries LLC PDUs which are used in layer 2 signalling. 
Information exchange between LLC and MAC: 

• the TMA-SAP route corresponds to the TMA-SAP, and carries primitives and local information exchange; 

• the TLE-SAP route corresponds to the TLE-SAP, and carries primitives. 

NOTE: The creation of the routes is considered to be an implementation issue and they are not shown in 
figure 22.2. 



22.2 Scenarios on LLC procedures 



This clause describes scenarios for normal TL-SDU transfer cases. For clarity many details such as TL-REPORT 
indication primitives are not included into message sequence diagrams. 

22.2.1 Basic link mode 

The basic link is available for information transfer whenever the MS is synchronized to a BS. There are two data 
transfer modes, acknowledged and unacknowledged PDU transfer. The acknowledged data transfer can be used for 
point-to-point communication and the unacknowledged data transfer can be used both for point-to-multipoint and 
point-to-point communication. 

22.2.1 .1 Acknowledged PDU transfer (BL-DATA + BL-ACK) 

Figures 22.3 and 22.4 show the transfer of information when the basic link is used. This protocol supports a message 
pair exchange based on primitives TL-DATA request and TL-DATA indication in one direction and on primitives 
TL-DATA response and TL-DATA confirm in the other direction as shown in figure 22.3. The TL-SDU from the left 
hand side entity is transmitted in the BL-DATA PDU. The TL-SDU in the TL-DATA response primitive from the right 
hand side LLC to the left hand side LLC is transferred in the BL-ACK PDU. That TL-SDU is not acknowledged 
directly with an explicit transfer of an acknowledgement PDU (though the left hand side entity may retransmit its 
BL-DATA PDU if it does not receive the BL-ACK PDU). Each BL-DATA PDU carries a TL-SDU number N(S), 
which indicates the number of the present BL-DATA PDU in that direction of information flow. The peer entity 
acknowledges the successful reception of this BL-DATA PDU by sending the same TL-SDU number N(R) in the 
acknowledgement BL-ACK PDU, see figure 22.4 for the PDU exchange. 

NOTE: This protocol uses in the acknowledgement message the same message number as in the received data 
message in contrary to most HDLC protocols, which typically rely on a continuous message exchange 
and use in the acknowledgement the next expected message number. 
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TL-DATA TL-DATA 
request confirm 



:^k_ 



LLC 



If 



BL-ACK 



TL-DATA TL-DATA 
response indication 



■^ 



/N 



:^l^ 



LLC 



BL-DATA 
Figure 22.3: Basic WnW PDU exchange with acicnowledgement carrying a layer 3 message 



LLC A 

TL-DATA request 



BL-DATA 



LLCB 



TL-DATA indication 
TL-DATA response 



BL-ACK TL-DATA response See note 

TL-DATA confirm 

NOTE: BL-ACK includes tine response data from the service user. 

Figure 22.4: Basic linit data transfer and acltnowledgement with a layer 3 message 

In the previous scenario there was a layer 3 TL-DATA response primitive available when the BL-ACK PDU was sent. 
If there is no layer 3 information available, then a short acknowledgement PDU is sent as shown in figures 22.5 
and 22.6. The LLC assumes that the LLC service user will normally provide a TL-DATA response to the TL-DATA 
indication primitive before the LLC and MAC has the next opportunity to send the BL-ACK PDU as shown above. If 
the TL-DATA response primitive is offered to the LLC after the sending of the BL-ACK PDU, then the LLC sends it as 
if it were a TL-DATA request primitive using a BL-DATA PDU, which is presented to the receiving service user as a 
TL-DATA indication primitive and will be confirmed, see the second set of primitives in figures 22.5 and 22.6. 



TL-DATA 
request 



/N 



TL-DATA 

confirm 

TL-DATA 

indication 



:^ 



TL-DATA 
response 
TL-DATA 
request 



LLC 



If 



BL-ACK 
BL-DATA 



■^ 



/N 



TL-DATA 

indication 
TL-DATA 
confirm 



:^LiL 



LLC 



BL-ACK 
BL-DATA 

Figure 22.5: Basic link PDU exchange with LLC acknowledgement with a delayed response 



LLC A 

TL-DATA request 

TL-DATA confirm 
TL-DATA indication 



BL-DATA 

BL-ACK 
BL-DATA 
BL-ACK 



LLCB 



TL-DATA indication 



TL-DATA response 



See note 1 



See note 2 



TL-DATA confirm See note 2 

NOTE 1 : When there is no TL-DATA response available, then LLC sends an acknowledgement without data. 
NOTE 2: The LLC transfers a delayed TL-SDU in the TL-DATA response primitive using normal acknowledged 

service as if it were a TL-DATA request primitive and a successful transfer will be confirmed with a 

TL-DATA confirm primitive to the service user. 

Figure 22.6: Basic link data transfer and acknowledgement with a delayed layer 3 response 
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The basic link also allows concurrent data transfer in both directions independent of each other as shown generally in 
figure 22.7 and as an example in figure 22.8. A TL-DATA request primitive is sent in a BL-DATA PDU from the 
LLC A. The LLC B may combine the acknowledgement and the user data from a TL-DATA request primitive into a 
BL-ADATA PDU. At the LLC A receiver the acknowledgement will be delivered to the service user in a TL-DATA 
confirm primitive and the user data is delivered in an independent TL-DATA indication primitive. The example 
continues with the second TL-DATA request primitive and with the corresponding combined BL-ADATA PDU. To the 
resulting TL-DATA indication primitive the LLC B responds with a TL-DATA response primitive and the user data is 
sent in a BL-ACK PDU. This is delivered to the service user in a TL-DATA confirm primitive and there is no explicit 
acknowledgement sent to that data. The next user data PDU from the LLC A will be a BL-DATA PDU and it is in this 
example acknowledged by a BL-ACK PDU without data. If the user does not want to send a response but an 
independent data, see figure 22.8 note 1, then a TL-DATA request primitive is used and the LLC will acknowledge the 
received data either with a BL-ACK or with a BL-ADATA PDU. In figure 22.7 there are two sets of service primitives; 
the upper and lower are used in the information flow from left to right and from right to left respectively. 



TL-DATA 
request 

TL-DATA 
response 



TL-DATA 

confirm 

TL-DATA 

indication 



:ikL 



LLC 



TL-DATA 
response 

TL-DATA 
request 



/N 



If 



BL-ACK 
BL-DATA, BL-ADATA 



BL-DATA, BL-ADATA 
BL-ACK 



^ 



TL-DATA 

indication 

TL-DATA 
confirm 
/1\ 



.:^l^ 



LLC 



Figure 22.7: Concurrent independent message exchange in both directions 



LLC A 

TL-DATA request 



TL-DATA confirm 

TL-DATA indication 

TL-DATA request 



TL-DATA confirm 
TL-DATA request 



BL-DATA 



BL-ADATA 



BL-ADATA 



BL-ACK 



BL-DATA 



BL-ACK 



LLCB 



TL-DATA indication 
TL-DATA request 



TL-DATA confirm 
TL-DATA indication 
TL-DATA response 



TL-DATA indication 



See note 1 



See note 2 



TL-DATA confirm 
NOTE 1 : Service user offers a data request instead of a response. 

NOTE 2: There may be also a data response, which is carried in BL-ACK PDU and will not be acknowledged 
directly. 



Figure 22.8: Concurrent independent message exchange in both directions 

The LLC sends reports, or reports on the progress of data sending, to the service user based on information from MAC 
layer. Those reports will be explained in the protocol description and are not presented here. 

In this protocol, a single TL-SDU, in a BL-DATA or BL-ADATA PDU, is sent and acknowledged at a time and the 
window size is equal to 1 . There is no peer-to-peer flow control mechanism for the basic link. 
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22.2.1 .2 Unacknowledged data transfer (BL-UDATA PDU) 

Unacknowledged mode of operation may be used for sending data from the base station to a group of MSs 
(point-to-multipoint) as shown in figures 22.9 and 22.10, where the BL-UDATA PDU is used to transfer information. 
No responses nor acknowledgements are expected to a BL-UDATA PDU. The sending LLC entity may repeat a 
BL-UDATA PDU several times to increase the probability of a correct reception. The receiving protocol does not 
suppress received duplicates. The unacknowledged basic link service does not guarantee in-order delivery at the 
receiving entity if the BL-UDATA PDU is repeated. The LLC may send a report or reports on the progress of data 
sending to the service user. 

The BL-UDATA PDU may be used also for sending data from the base station to an individual MS (point-to-point) or 
from an MS to the base station. 



TL-UNITDATA 

indication 



LLC 



If 



BL-UDATA 



TL-UNITDATA 
request 



LLC 



Figure 22.9: PDU exchange in unacltnowledged mode 



LLC A 



BL-UDATA 
TL-UNITDATA indication 
Figure 22.10: Basic linit data transfer in unacl<nowledged mode 



LLCB 

TL-UNITDATA request 



22.2.1 .3 Unacknowledged data transfer with presence indication 
(BL-DATA + BL-ACK PDU) 

This clause describes how a BS may implement presence checking in group call establishment. 

This operation mode of the BS allows sending of unacknowledged data and requesting a low level presence indication 
from one or more recipient MS. The presence indication message carries only indication that at least one MS has 
received the message correctly and shall not contain a TL-SDU, see figures 22.1 1 and 22.12. In response to the 
TL-DATA request primitive with a presence indication parameter the base station sends a normal BL-DATA PDU and 
waits for an answer from one or more MSs. The MS LLC sends a normal acknowledgement, which is detected in the 
BS without actually decoding it especially if many MSs have answered at the same time. The BS LLC does not re-send 
the BL-DATA PDU to get back a decodeable BL-ACK PDU, but it may send BL-DATA PDU more than once for more 
reliable data transfer. 



TL-DATA 

indication 



LLC 



If 



BL-DATA 



TL-DATA TL-DATA 
request confirm 



■^ 



LLC 



BL-ACK 
Figure 22.11 : Basic linit data transfer with presence indication 
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MS LLC 



TL-DATA indication 




BSLLC 

TL-DATA request 



TL-DATA request primitive 
with presence request 



TL-DATA confirm No user data 

Figure 22.12: Basic linit data transfer with presence indication 



22.2.2 Advanced link 

The advanced link provides two data transfer services, i.e. acknowledged and unacknowledged PDU transfer. The 
acknowledged data transfer can be used for point-to-point communication and the unacknowledged data transfer is 
intended to be used for point-to-multipoint communication, but may also be used for point-to-point information transfer 
on the downlink. Both services of the advanced link need to be set up before they can be utilized. The life of an 
advanced link comprises a connection set-up, data transfer and connection release. The life time of an advanced link 
may be limited or unlimited. After cell reselection, depending on the capabilities of the MS and SwMI, the advanced 
link may be reconnected, with the same parameters (e.g. QoS, timers, counters) as were used on the previous cell. 

The advanced link protocol can send multiple TL-SDUs before an acknowledgement shall be sent or is received. The 
transmitting station may send up to N.272 TL-SDUs before requesting and receiving a specific acknowledgement. The 
LLC may re-send TL-SDUs under a request from the receiving LLC entity or due to a lack of an acknowledgement. 

The advanced link segments TL-SDUs which are too long to be carried in one advanced link unit, and applies automatic 
selective re-transmission to badly received segments: 

• When on a 7i/4-DQPSK or D8PSK channel, the segment size is determined by the available room in a MAC 
transmission unit (MAC block). Therefore, on a D8PSK channel, segments may be of different sizes, 
depending on whether they are cut to be sent using 7i/4-DQPSK or 71/8-D8PSK modulation for the first 
transmission of that segment. 

• When on a 25 kHz or 50 kHz QAM channel, the segment size is normally determined by the available space in 
a 4-QAM rate = V2 full-slot MAC block at the current bandwidth; when on a 100 kHz or 150 kHz QAM 
channel, the segment size is normally determined by the available space in half of a 4-QAM rate = Vi full-slot 
MAC block at the current bandwidth. The first and last segment of a TL-SDU may be of different size. 

There are two variants of advanced link: the original advanced link and the extended advanced link. The type of 
advanced link is negotiated during the call set-up. The MS is only permitted to support one original advanced link per 
service, whereas it may support more than one extended advanced link per service, provided that the total number of 
advanced links (original plus extended) is not more than four per service. (This refers to the services available for one 
address.) 

• For the original advanced link, there is not explicit link numbering in the data transfer and acknowledgement 
PDUs; the advanced link number is implicitly assumed to be as indicated in the set-up message for the original 
advanced link. The FCS is mandatory for the original advanced link. 

• In the extended advanced link, there is explicit link numbering in all the data transfer and acknowledgement 
PDUs. The FCS is optional for the extended advanced link. And the extended advanced link has a larger 
TL-SDU sequence number than the original advanced link, enabling a larger TL-SDU window size. 

The PDUs used for advanced link set-up, release and reconnection are the same for the original advanced link and the 
extended advanced link. However there are different PDUs for the data transfer and acknowledgements; extended 
advanced link PDUs are indicated by "-X" included in the name of the corresponding original advanced link PDU. 

EXAMPLE: For example, the AL-DATA PDU is used on the original acknowledged advanced link to send 
segments other than the last - and the equivalent PDU for the extended advanced Unk is denoted 
AL-X-DATA. 
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22.2.2.1 Setting up the connection mode (AL-SETUP PDU) 

The advanced LLC link connection for acknowledged service shall be negotiated between the two LLC entities as 
described in figures 22.13, 22.14 and 22.15. Either the MS or BS may initiate the advanced link connection set-up. A 
new connection set-up using the same advanced link number (and address) during an already existing connection 
overrides it and performs a link reset. 

The resulting connection mode advanced link may coexist with an unacknowledged advanced link, refer to 
clause 22.2.2.2. 

A new acknowledged advanced link set-up using a different advanced link number or address during an already existing 
acknowledged advanced link (or already existing acknowledged advanced links) sets up a new, independent, advanced 
link. 

The connection request contains all parameters for negotiation (see note 1): 

• the maximum length of the TL-SDU N.271; 

• the allowed number of TL-SDU retransmissions before LLC gives up N.273; 

• the LLC TL-SDU window size N.272; 

• the number of retransmissions of a segment N.274; 

• optionally, the number of 7i/4-DQPSK timeslots used per a TDMA frame N.264 (see note 2); 

• optionally, the requested mean value for the data transfer throughput (see note 2); 

• the number of advanced link N.26 1 ; and 

• indication of whether the advanced link is an original or extended advanced link. 

The negotiation uses AL-SETUP PDUs. 

NOTE 1 : These constants are part of the quality of service negotiation and are transmitted to the peer side. 

Depending on the mobile class and base station services, the peer entity may wish to respond with a lower 
quality of service or even refuse the connection set-up. 

NOTE 2: The AL-SETUP PDU may contain information related to radio resources; this facility in the AL-SETUP 
PDU provides resource information only in terms of 7i/4-DQPSK timeslots. Alternatively (for example, if 
QoS information has been negotiated by the SNDCP during PDP context activation), the AL-SETUP 
PDU may provide no information related to radio resources. 

The resulting connection will support two-way exchange of information between the peer LLC entities. 
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Figure 22.13: PDU setting up the advanced link 
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Figure 22.14: Advanced linl< set-up 
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NOTE 3: On establishment of an advanced link, the LLC prepares an AL-SETUP PDU with a setup report "service 
definition" if the corresponding advanced link is not already set-up. However, after advanced link 
continuation, the MS LLC may think that there is already an established advanced link and therefore use a 
setup report value of "reset". Then the BS LLC entity should start normal connection establishment as if 
the received report were "service definition". 



LLC A 
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TL-CONNECT response 



TL-CONNECT confirm 



AL-SETUP 



AL-SETUP 



AL-SETUP 



LLCB 

TL-CONNECT request 
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See note 1 

See note 1 
See note 2 



NOTE 1 : Proposed QoS is not acceptable and a new QoS is proposed. Tlie service negotiation may be 

performed as an direct negotiation between tlie LLC entities. 
NOTE 2: The lower QoS is accepted 

Figure 22.15: Advanced link set-up to a lower quality of service 

Figure 22.14 presents a message sequence diagram for an advanced link set-up, when the LLC B accepts the quality of 
service proposed by the LLC A. If the receiving station replies with a lower parameter setting, the transmitting station 
shall confirm those lower values and use these negotiated parameters for the advanced link as shown in figure 22.15. A 
receiving station shall not reply with higher parameter setting. On the other hand, the receiving station may refuse the 
connection by returning a TL-DISCONNECT request primitive (AL-DISC PDU). 

The initial connect request shall set the TL-SDU and segment counters to the default values prior to the first 
transmission in both information flow directions. 

If the LLC cannot support the advanced link, it may send an AL-DISC PDU, see figure 22.16. 

LLCB 



LLC A 

TL-CONNECT request 



AL-SETUP 



AL-DISC 
TL-DISCONNECT indication 

Figure 22.16: Unsupported service indication 



TL-CONNECT indication 
(TL-DISCONNECT request) 



22.2.2.2 Setting up the unacknowledged transfer mode (AL-SETUP PDU) 

The advanced LLC link parameters shall be informed to the future participants of the unacknowledged transfer mode 
before the data transfer may commence successfully as described in figures 22.17 and 22.18. A new unacknowledged 
advanced link set-up using the same advanced link number and address during an already existing unacknowledged 
advanced link only modifies advanced link parameters without a reset functionality e.g. TL-SDU numbering shall 
continue without interruption. This set-up does not affect to the existing acknowledged advanced link service, if any, 
refer to clause 22.2.2. 1. 

A new unacknowledged advanced link set-up using a different advanced link number or address during an already 
existing unacknowledged advanced link (or already existing unacknowledged advanced links) sets up a new, 
independent, advanced link. 

The set-up indication contains all relevant parameters for the unacknowledged advanced link: the maximum length of 
the TL-SDU N.271, the maximum number of TL-SDU retransmissions N.282, the LLC TL-SDU window size N.281 
and indication of whether the advanced link being set up is an original or extended advanced link. The AL-SETUP PDU 
transmits these parameters. The AL-SETUP PDU may be sent several times (N.282H-1 times) to increase the probability 
of correct reception. The further connection attempts for the same link are not passed to the service user unless the 
parameters in the following AL-SETUP PDUs change. 
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The resulting unacknowledged advanced link will support one-way exchange of information from the entity which 
sends the set-up information to the other peer LLC entities. The receiving entity may not be capable to conform to the 
selected parameters and may neglect the set-up. 
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Figure 22.17: Unacknowledged transfer mode set-up of the advanced link 
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Figure 22.18: Unacknowledged transfer mode set-up of the advanced link 

The unacknowledged advanced link entities shall set the TL-SDU and segments counters to the default values prior to 
the first transmission. 

22.2.2.3 Data exchange in the connection mode (AL-DATA or AL-X-DATA PDU) 

After the connection set-up the advanced LLC link is ready for a two-way exchange of information between the two 
peer LLC entities although actual information flow could be unidirectional and the other direction is used only for 
acknowledgements. The information flows in both directions (uplink and downlink) are independent of each other. Each 
AL-DATA or AL-X-DATA PDU contains two numbers: the actual TL-SDU number N(S) and the absolute position of 
the segment inside the TL-SDU called segment sequence number S(S). The segment sequence number is used in 
selective re-transmission in the AL-ACK or AL-X-ACK PDU. The AL-X-DATA PDU also contains the advanced link 
number. 

The remainder of this clause describes scenarios for data exchange in the connection mode on the original advanced 
link. The methods of data exchange in the connection mode on an extended advanced link are similar to the methods on 
the original advanced link - except that PDUs AL-X-DATA, AL-X-DATA-AR, AL-X-FINAL, AL-X-FINAL-AR, 
AL-X-ACK and AL-X-RNR are used instead of PDUs AL-DATA, AL-DATA-AR, AL-FINAL, AL-FINAL-AR, 
AL-ACK and AL-RNR respectively. 

NOTE: If an MS is using more than one advanced link, the data transfer procedures for each advanced link 
operate independently of the data transfer procedures for the other advanced link(s). 

Data transfer in the advanced LLC link can be either unidirectional or bidirectional. In both cases data sending and data 
acknowledgements use the same PDUs and protocol. In the first case, the transfer flow is shown in figures 22.19 
and 22.20 for the original advanced link. In this example LLC A sends a segmented TL-SDU using AL-DATA PDUs 
and marks the last segment of the TL-SDU by using an AL-FINAL-AR PDU. In reply to the AL-FINAL-AR PDU the 
receiving LLC shall generate an acknowledgement using an AL-ACK PDU. The sending LLC informs the service user 
of the correct transfer of the layer 3 TL-D ATA by issuing a TL-DATA confirm primitive when a whole TL-SDU has 
been acknowledged. The receiving BS LLC entity informs the service user of the incoming of data by issuing a 
TL- RECEIVE indication primitive. 
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Figure 22.19: PDU exchange in a unidirectional transfer on the original advanced link 
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See note 



The last segment is sent using 
AL-FINAL-AR 

LLC B acknowledges the TL-SDU 



TL-DATA confirm 

NOTE: LLC B refers to BS LLC entity in this figure. Exact mechanism when to send the TL-RECEIVE 
indication primitive is outside the scope of the present document. 

Figure 22.20: PDU exchange in a unidirectional transfer on the original advanced link 

The sending LLC entity may request an acknowledgement from the peer entity at any time by using AL-DATA-AR or 
AL-FINAL-AR PDUs in place of the AL-DATA and AL-FINAL PDUs respectively. The sender may continue 
transmission of data without waiting for the requested acknowledgements, if allowed by the SDU window size. In 
figure 22.21 the LLC B requests an acknowledgement in the middle of sending a TL-SDU and later does not request an 
immediate acknowledgement to the complete TL-SDU. 

The receiver may send an AL-ACK PDU at any time in addition to the requested acknowledgements, see also 
clause 22.2.2.7. 
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TL-DATA confirm 
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NOTE: LLC A refers to BS LLC entity in this figure. Exact mechanism when to send the TL-RECEIVE 
indication primitive is outside the scope of the present document. 

Figure 22.21 : A longer PDU transfer on the original advanced link 

An example of bidirectional information transfer flow is shown in figures 22.22 and 22.23. The LLC A sends a message 
to the LLC B, and the LLC B responds with another message. The LLC A starts the sending by a segmented TL-SDU 
using AL-DATA PDUs and marks the last segment of the TL-SDU by using AL-FINAL-AR PDU. The LLC B delivers 
the received TL-SDU to the service user as a TL-DATA indication primitive. The LLC B generates an 
acknowledgement AL-ACK PDU as a response to the AL-FINAL PDU. The acknowledged TL-SDU shall be indicated 
to the sending service user by a TL-DATA confirm primitive. 
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Figure 22.22: Bi-directional data transfer on the original advanced link 
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See note 3 



NOTE 1 : LLC B refers to BS LLC entity in this figure. Exact mechanism when to send the TL-RECEIVE 

indication primitive is outside the scope of the present document. 
NOTE 2: The last segment is sent using AL-FINAL-AR. 
NOTE 3: LLC B sends a responding or independent TL-SDU. 

Figure 22.23: Bi-directional PDU transfer on the original advanced link 

The LLC can accept more than one TL-SDU for sending before completing the transfer of the previous TL-SDU. The 
LLC may also modify the sending order of TL-SDUs depending on the priorities of those SDUs, but all already started 
transmissions need to be completed before a new higher priority TL-SDU (non pre-emptive) may be transferred 
successfully. The LLC entity could also start sending of TL-SDUs at any time independently of the state of the other 
transfer direction. 

Highest priority transmissions across an advanced link may reset the link to get fast access. This action may corrupt the 
ongoing lower priority transmission. 

22.2.2.4 Data exchange in the unacknowledged transfer mode (AL-UDATA or 
AL-X-UDATA PDU) 

After the unacknowledged data transfer set-up the advanced LLC link is ready for a one-way exchange of information. 
The service user data is transmitted in AL-UDATA or AL-X-UDATA PDUs. The AL-UDATA or AL-X-UDATA PDU 
contains two numbers: the actual TL-SDU number N(S) and the absolute position of the segment inside the TL-SDU 
called segment sequence number S(S). The segment sequence number is used in the rebuilding of the received TL-SDU 
from segments. The AL-X-UDATA PDU also contains the advanced link number. 

The data transfer flow is shown in figures 22.24 and 22.25 for the original advanced link. The methods of 
unacknowledged data exchange on an extended advanced link are similar to the methods on the original advanced link - 
except that PDUs AL-X-UDATA and AL-X-UFINAL are used instead of PDUs AL-UDATA and AL-UFINAL 
respectively. 

NOTE: If an MS is receiving more than one unacknowledged advanced link, the data transfer procedures for each 
advanced link operate independently of the data transfer procedures for the other advanced link(s). 

In the example shown, the BS LLC sends a segmented TL-SDU using AL-UDATA PDUs and marks the last segment 
of the TL-SDU by using an AL-UFINAL PDU. The BS may send the TL-SDU several times up to maximum 
retransmissions (N.282) to increase the reception probability (and using the same segmentation for each repetition). 

The receiving LLC entity delivers the TL-SDU to the service user in a TL-UNITDATA indication primitive. The 
sending entity may inform the completion of all repetitions to the service user using an informal TL-UNITDATA 
confirm primitive. 
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Figure 22.24: PDU sending in a unidirectional transfer on thie original advanced link 
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Figure 22.25: PDU sending in a unidirectional transfer on the original advanced link 

The BS LLC may send repetitions of up to N.281 TL-SDUs in any order, but either the oldest TL-SDU within that 
SDU- window with all repetitions shall be sent, or transmission of the oldest TL-SDU within the SDU-window shall be 
stopped, before a new TL-SDU may commence. The BS LLC may also modify the sending order of TL-SDUs 
depending on the priorities of those SDUs. 

The receiving entity may combine segments from multiple transmissions of the same TL-SDU in order to reassemble a 
complete TL-SDU. 



22.2.2.5 



Window mechanism 



In the advanced link LLC protocol there is a window mechanism for TL-SDU transmissions. The window mechanism 
allows more than one TL-SDU and LLC data PDU respectively to be sent before required acknowledgements stop LLC 
transmissions. The TL-SDU window size N.272 is negotiated during the advanced link set-up, refer to clause 22.2.2. L 
The maximum window size that may be negotiated is: 

• 3 for the original advanced link; or 

• 15 for an extended advanced link. 

The receiving LLC entity may acknowledge each TL-SDU as soon as it is fully received, but the sending LLC entity 
may continue to send up to a total of N.272 TL-SDUs before receiving acknowledgements for the previous TL-SDUs. 
(For window size N.272 = 1, the receiving LLC entity acknowledges each TL-SDU before the sending LLC entity may 
continue with the next TL-SDU.) 

During a segment transmission the sending LLC entity may force a sending of an acknowledgement whenever it sends 
the last segment of a TL-SDU, which is sent as the AL-FINAL-AR or AL-X-FINAL PDU, refer to clause 22.2.2.3. The 
sending LLC entity may also request an acknowledgement at any time using an AL-DATA-AR or AL-X-DATA-AR 
PDU type, which also initiates an acknowledgement as soon as possible. This is illustrated for the original advanced 
link in figures 22.26 and 22.27. 

This window mechanism shall not be used for flow control purposes, refer to clause 22.2.2.7. 
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Figure 22.26: PDU exchange for forced acknowledgement on the original advanced link 
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NOTE: LLC B refers to BS LLC entity in this figure. Exact mechanism when to send the TL-RECEIVE 
indication primitive is outside the scope of the present document. 

Figure 22.27: Forced acknowledgement on the original advanced link 
22.2.2.6 Selective re-transmission of segments (AL-ACK or AL-X-ACK PDU) 

The selective re-transmission is based on the segments (LLC PDUs) into which the transmitting LLC divides a TL-SDU 
for sending. The receiving LLC informs the transmitting LLC which segments are not received correctly, and then the 
transmitting LLC sends the missing segments in the later transmissions until the whole TL-SDU is received correctly as 
recognized by the MAC layer error detection. The whole TL-SDU may still be erroneous and the receiving entity shall 
ask a re-transmission, when an error in the TL-SDU is detected by the frame check sequence. 

Figure 22.28 shows an example of a selective re-transmission sequence for the original advanced link. Line a) of 
figure 22.28 shows three TL-SDUs, which the LLC divides into segments as shown in the line b). The end of each SDU 
is marked by "F" and the LLC sends that segment using a AL-FINAL PDU. The SDU window size is 2 in this example. 

The transmitting LLC plans to send segments as shown on line b) of figure 22.28 and starts to send them in sequence 
using AL-DATA PDUs for all but the last one which it sends using AL-DATA-AR PDU marked by "A". The receiving 
LLC receives correctly segments 1, 2, 4, 5 from the first SDU as shown on line c), and sends the first acknowledgement 
(ACK) as requested by the sending entity. The acknowledgement contains bit maps as shown on line e) and 
corresponding segment numbers are shown on line f). The first part of the ACK (1/3) indicates the first segment, which 
is not received correctly, in this example segment number 3 in the first SDU and a bit map from that segment onwards. 
The acknowledgement tells that all segments before the 3rd segment of the first SDU (1/3) are received correctly and 
that segment 3 of the first SDU is not yet received correctly. Then the bitmap shows that segments 4 and 5 are received 
correctly. 
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The transmitting LLC then modifies its transmission and adds those segments, which were not acknowledged or sent 
i.e. 3 and 6 from the first SDU (1/3 and 1/6), before continuing transmission of new segments in this case from the 
second SDU. The last segment of the second SDU is sent as AL-FINAL-AR PDU marked "F/A". The second and third 
acknowledgements on line d) indicate that again segments 3 and 6 from the first SDU are not yet received correctly, but 
the second SDU is received totally and correctly (2/ A). The transmitting LLC then re-sends segments 3 and 6 of the first 
SDU and cannot continue to the third SDU due to SDU window size of two in this example. 

The receiving LLC misses again the segment number 3 of the first SDU as shown on line g) and the receiving LLC 
sends acknowledgement after receiving the 6th and final segment of the first SDU. The first acknowledgement indicates 
that only the third segment of the first SDU is not yet received correctly. The transmitting LLC then re-sends the 
missing segment of the first SDU and after receiving the second acknowledgement on the line h) can send the third 
SDU, which fits into the new SDU window. That SDU is received correctly as indicated by each segment CRC, but the 
total frame check sequence does not match and the receiving LLC sends an acknowledgement indicating a re-sending 
request (3/F) of the third SDU. After re-sending on line j) the third SDU is this time received correctly and 
acknowledged on line k) (3/A). 

In this example the receiving LLC will deliver the first TL-SDU to the MLE only after sending the second 
acknowledgement on the line i), which indicates that the first SDU is correctly received. The second SDU is already 
correctly received and acknowledged by the second acknowledgement on the line d), but the receiving LLC cannot 
deliver it before the first SDU is received in order to keep the SDUs in the correct sequence. 
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Figure 22.28: Selective re-transmission example 

If the AL-FINAL-AR is lost and there is no more data to send or the transmission window is closed and the last 
acknowledgement is also lost, then the sending entity may repeat the whole last sending or only the segments which 
were sent with the acknowledgement request. 
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22.2.2.7 Flow control (AL-RNR or AL-X-RNR PDU) 

The receiving advanced link entity may at any time request its peer entity to stop transmission of data PDUs on an 
advanced link by sending an AL-RNR PDU (for the original advanced link) or an AL-X-RNR PDU (for an extended 
advanced link). The AL-RNR or AL-X-RNR PDU replaces the AL-ACK or AL-X-ACK PDU, when the receiver is not 
ready to receive new PDUs. The re-transmission of the segments or PDUs indicated in the AL-RNR or AL-X-RNR 
PDU shall continue. The data transmission may continue after the receiving entity has sent an AL-ACK or AL-X-ACK 
PDU for this advanced link. This is illustrated for the original advanced link in figures 22.29 and 22.30. 

The receiver not ready indication is valid from the last received AL-RNR or AL-X-RNR PDU for this advanced link for 
the duration of T.271 s, after which the transmitter may try to re-start data sending. 
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Figure 22.29: Flow control PDU exchange on the original advanced link 
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NOTE: LLC B refers to BS LLC entity in this figure. Exact mechanism when to send the TL-RECEIVE 
indication primitive is outside the scope of the present document. 

Figure 22.30: Flow control on the original advanced link 

22.2.2.8 Connection reset 

The connection reset may be performed using connection set-up procedure, refer to clause 22.2.2.1. 
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22.2.2.8a Reconnecting an advanced link (AL-RECONNECT PDU) 

Prior to performing a cell handover, the LLC service user may request that an advanced link is locally disconnected by 
using the TL-RELEASE request primitive. However, where the MS is involved in the transmission or reception of 
TL-SDU segments immediately prior to cell handover, the LLC service user may decide not to disconnect the advanced 
link but instead may request the LLC to reconnect the advanced link on the new cell by using TL-RECONNECT 
request primitive, when the SwMI supports or recognizes the advanced link roaming, and thus continue the transmission 
or reception of TL-SDU segments from where it finished on the previous cell. When the MS initiates a reconnection, 
see figures 22.3 1 and 22.32, the timer T.265 (Reconnection waiting timer) shall be started at the TL-RECONNECT 
request primitive. On reception of the AL-RECONNECT PDU, and where the reconnection has been successful as 
indicated by the reconnect report field value "success", the LLC shall send a TL-RECONNECT confirm primitive to the 
service user to indicate the successful result of the reconnection, a TMC -CONFIGURE request primitive to the MAC in 
order to accept the channel change when requested and the MS LLC may continue using the advanced link on the new 
cell without a reset. 



NOTE: When the MS moves to a new cell, it should not send any TMA-UNITDATA request primitives 
containing TL-SDU segments for an advanced link until that advanced link has been successfully 
reconnected on the new cell (or set up again or reset). 

On reception of the AL-RECONNECT PDU, and where the reconnection attempt has failed as indicated by the 
reconnect report field value "reject", or when timer T.265 has expired N.265 times (maximum number of reconnection 
retries), without success, then MS LLC shall consider that the reconnection of the advanced link has failed and inform 
the service user by a TL-RECONNECT confirm primitive with the reconnection result set to "reject" or "failed" 
respectively. 

If the MS is involved in the transmission or reception of TL-SDU segments on more than one advanced link 
immediately prior to cell handover, the LLC service user may request the LLC to reconnect some or all of the advanced 
links on the new cell by using multiple TL-RECONNECT request primitives. The LLC then performs the reconnection 
procedure for each of those advanced links. It may then continue the transmission or reception of TL-SDU segments on 
those advanced links for which reconnection was successful from where it finished on the previous cell. 
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Figure 22.31 : PDU exchange for reconnection of the advanced link 
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Figure 22.32: Reconnection of an advanced linlc 
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22.2.2.9 Releasing an acknowledged advanced link (AL-DISC PDU) 

An advanced link may be closed at any time by using the TL-DISCONNECT request primitive. Any ongoing data 
transfer shall be stopped immediately with the possible result of data loss, refer to figures 22.33 and 22.34. When the 
LLC starts a disconnection, see figure 22.34, then the timer T.263 shall be started at the TL-DISCONNECT request 
primitive. On a reception of AL-DISC or when timer T.263 has expired N.263 times without success, a 
TL-DISCONNECT confirm primitive is given to the service user. The LLC shall discontinue to use the advanced link 
immediately at the reception of an AL-DISC PDU. 
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Figure 22.33: PDU exchange for releasing the advanced linl< 
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Figure 22.34: Disconnection of an advanced linit 



22.2.2.1 Releasing an unacknowledged advanced link (AL-DISC PDU) 

An unacknowledged advanced link is suppressed by using the disconnect primitive, refer to figures 22.35 and 22.36. 
The AL-DISC PDU may be repeated to increase reception probability. The further disconnection attempts for the same 
link are not passed to the service user. Disconnection may occur at any time and after that instance that 
unacknowledged link does not support unacknowledged data transfer. 



TL-DISCONNECT 

indication 



LLC 



If 



AL-DISC 



TL-DISCONNECT 
request 



LLC 



Figure 22.35: PDU exchange for releasing the unacknowledged advanced link 
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Figure 22.36: Disconnection of an unacknowledged advanced link 
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22.2.3 Layer 2 signalling 



In addition to basic link and advanced link signalling PDUs, the LLC may send and receive layer 2 signalling PDUs; 
these PDUs carry various types of general signalling information relating to layer 2 functions. The layer 2 functions 
may be either LLC or MAC functions. However, for the purposes of the data exchange mechanisms, the layer 2 
signalling PDUs are treated as LLC PDUs. 

In the present document, the layer 2 signalling PDUs are used only for MAC functions. Valid layer 2 signalling PDUs 
are as follows: 

• the MS may send the L2-DATA-PRI0RITY or L2-LINK-FEEDBACK-INFO or L2-LINK-FEEDB ACK- 
INFO-AND-RESIDUAL-DATA-PRIORITYPDU; 

• the BS may send the L2-SCHEDULE-SYNC or L2-LINK-FEEDBACK-CONTROL or 
L2-LINK-FEEDBACK-INFO PDU. 

Where a layer 2 signalling PDU relates to a MAC function, the LLC provides the layer 2 signalling service to the MAC 
through the TLE-SAP. Then: 

• in the case of transmission, information to be included in the layer 2 signalling PDU is passed from the MAC 
to the LLC using the TLE-UNITDATA request primitive; then the LLC shall format and send the layer 2 
signalhng PDU; 

• in the case of reception, the LLC shall pass the information contained in the layer 2 signalling PDU to the 
MAC using the TLE-UNITDATA indication primitive. 

NOTE: The sending LLC entity may issue a report or reports on the progress of the data sending to the MAC. 

When the LLC sends or receives a layer 2 signalling PDU, it uses the data transfer service primitives offered by the 
MAC at the TMA-SAP. 

The data transfer is shown for an L2 -DATA-PRIORITY PDU in figures 22.37 and 22.38. 

The information transfer service provided by the layer 2 signalling procedures is an unacknowledged service. 

The sending LLC entity may repeat a layer 2 signalling PDU to increase the probability of a correct reception. The 
receiving LLC protocol does not suppress received duplicates. The layer 2 signalling service does not guarantee 
in-order delivery at the receiving entity. 
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22.3 LLC procedures 



In this clause the word "shall" is used with service primitives for traceability reasons in the protocol model, but the 
primitives are not testable and do not imply any implementation. 

22.3.1 Common procedures for all services 

This clause describes protocol procedures, which are used in all LLC services or which are common to all services. 

22.3.1 .1 Link identifiers, endpoint Identifiers and handle to the request 

Link identifiers between the service user (MLE) and LLC shall serve to distinguish between the multiple concurrent 
services, e.g. among several advanced links and their associated basic links. These identifiers may be local. 

The endpoint identifiers between the MLE and LLC, and between the LLC and MAC, refer to the MAC resource that is 
currently used for that service. These identifiers may be local. There shall be a unique correspondence between the 
endpoint identifier and the physical allocation (timeslot or timeslots) used in the MAC. (This correspondence is known 
only within the MAC.) More than one advanced link may use one MAC resource. 

Acknowledgement shall use the same endpoint identifier in the LLC. 

When the LLC receives a service request primitive (except TL-RELEASE request) from the MLE, the primitive 
includes a local identifier for the service request, referred to as the "handle to the request". The handle should be 
retained locally and used for identifying subsequent related service primitives. It refers to all actions required in the 
LLC to accomplish the request. LLC shall also pass the handle to the request parameter to the MAC layer. In a similar 
way the MAC associates a handle to the request to each data request and the LLC shall use that handle to the request 
when it refers to that transmission. 

The LLC shall generate a handle to the request for acknowledged data transfer service indication primitives (TL-DATA 
indication) and retain it for the corresponding response primitive (TL-DATA response). 

The handle to the request shall cease to exist, when the requested or offered service is completed successfully or 
unsuccessfully. 

22.3.1.2 Addressing 

At the transmitting LLC entity, the LLC shall get the address in use as a parameter from the service user in the primitive 
types request and response and shall give it to the MAC as a parameter. At the receiving entity, the LLC shall get the 
address in use from the MAC and shall give it to the service user in the primitive types indication and confirm as a 
parameter. The LLC shall copy the same address parameters as in the corresponding TMA-UNITDATA indication 
primitive to the acknowledging TMA-UNITDATA request primitive. 

NOTE: ITSIs and GTSIs in an MS are independent of each other and LLC services recognize addresses to allow 
concurrent basic or advanced link services. The present document does not describe how addresses affect 
to the LLC implementation. 

If layer 3 response address is different to the address in TMA-UNITDATA indication primitive then the layer 3 
response shall not be piggybacked on the layer 2 acknowledgement. 

22.3.1 .3 User data buffering 

The sending LLC entity shall buffer TL-SDUs in order to offer re-transmission until individually marked as correctly 
received, or the maximum number of retransmissions is exceeded or the TL-SDU is cancelled by the service user or, in 
addition in the case of an advanced link, the link is either disconnected or re-set. When transmitting segmented 
TL-SDUs, the segmentation and the segments shall be preserved for further retransmissions until the TL-SDU is 
completely acknowledged or the maximum number of retransmissions is exceeded. 

The LLC sub-entities shall update their part of the DATA_IN_BUFFER signal so often, that the MAC layer can update 
resource requests in time to prevent unnecessary breaks and random accesses in uplink data transfer, see 
clause 22.3. L7. 
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The amount of data that may be buffered for transmission inside LLC layer is implementation dependent. This model 
deletes all not yet transmitted data in the advanced link buffers, when the advanced link is reset by a new set-up. 

22.3.1 .4 Cancelling SDU transmission 

This procedure is local to the MS, but affects the data transfer over the air interface. 

On the basic link the service user may cancel an ongoing transmission of a TL-SDU. On the reception of a 
TL-CANCEL request primitive from the service user the LLC shall delete the TL-SDU indicated by the handle to the 
request parameter in the TL-CANCEL request primitive, if that TL-SDU is still in the transmission buffer and no part of 
it is transferred to the MAC layer, and shall indicate the cancellation to the service user in a TL-REPORT indication 
primitive (aborted, TL-SDU not completely sent). Otherwise LLC shall forward cancellation request to the MAC as a 
TMA-CANCEL request primitive. If the corresponding MAC TMA-REPORT indication primitive (aborted, TM-SDU 
not completely sent) shows that the MAC has aborted the transmission and the TM-SDU has not been completely sent, 
then the LLC shall delete the corresponding TL-SDU from the sending buffer and shall indicate the cancellation to the 
service user in a TL-REPORT indication primitive (aborted, TL-SDU not completely sent). If the MAC has sent the 
whole SDU containing the TL-SDU for which a cancellation was requested, then the MAC will indicate with a 
TMA-REPORT indication primitive (aborted, TM-SDU sent at least once) that the whole TL-SDU is sent. The LLC 
shall then delete the corresponding TL-SDU from the sending buffer and indicate in a TL-REPORT indication primitive 
(aborted, TL-SDU sent at least once) to the service user that the DLL has aborted sending actions but the TL-SDU has 
been sent at least once. 

NOTE 1 : If the LLC has transferred the SDU to the MAC more than once, then it is the LLC's responsibility to 
issue the correct TL-REPORT indication primitive to the higher layers, taking into account also the 
results of the previous transmission attempts. 

In the advanced link the DLL can cancel the transmission of the TL-SDU only if the first segment has not been sent at 
all. On the reception of a TL-CANCEL request primitive from the service user the LLC shall delete from the 
transmission buffer a TL-SDU, if sending has not started, and indicate in a TL-REPORT indication primitive that 
cancellation is completed and the TL-SDU is not sent. If the LLC has delivered only the first segment of the TL-SDU to 
the MAC and that segment is not yet acknowledged, then the LLC shall forward cancellation request to the MAC as a 
TMA-CANCEL request primitive. If the corresponding MAC TMA-REPORT indication primitive shows that the MAC 
has aborted the transmission and the TMA-SDU corresponding to the first segment has not been sent at all, then the 
LLC shall delete the corresponding TL-SDU from the sending buffer and shall indicate the successful cancellation (the 
TL-SDU is not completely sent) to the service user in a TL-REPORT indication primitive. 

If the TMA-REPORT indication primitive shows that the MAC has sent the TM-SDU corresponding to the first 
segment at least once, then the LLC shall indicate with a TL-REPORT indication primitive (layer two transmission 
activities continuing) and continue TL-SDU transmission. 

NOTE 2: The above applies to an MS. A BS LLC sending TL-SDUs on an unacknowledged advanced link may 
stop transmission of a particular TL-SDU at any time without disconnecting or resetting that 
unacknowledged advanced link. 

The advanced link service user may also stop transmission of a TL-SDU by disconnecting or resetting by a new set-up 
the corresponding advanced link, refer to clauses 22.3.3.3 and 22.3.3. L 

NOTE 3: The DLL always responds to a TL-CANCEL request primitive with a TL-REPORT indication primitive. 

22.3.1 .5 Extended error protection 

An extended error detection (ECS) shall be offered as a selectable part of the service on the basic link or an extended 
advanced link and as a mandatory part of the service on the original advanced link. When appropriate the sending LLC 
shall calculate over the TL-SDU a PCS and shall append it to the TL-SDU. 

When a ECS is appended to the TL-SDU, then the receiving LLC entity shall test the received TL-SDU against the PCS 
to detect whether errors have been introduced into the TL-SDU during transmission. When the receiving LLC detects 
errors in the received TL-SDU, the LLC shall not pass the erroneous TL-SDU to the service user, but instead the LLC 
shall discard the erroneous TL-SDU and enforce an SDU re-transmission if appropriate. 

The PCS is defined in annex C. 
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22.3.1 .6 Timers and counters 



In the protocol description, timers and counters are referred to either by their names or by their value symbols or both 
e.g. set-up waiting timer T.261 . Stopping of timers and counter re-settings are shown only when implicit reasons are not 
obvious. This protocol does not define or restrict any implementation of timers or counters. 

Some of the LLC timers are defined in terms of downlink signalling frames for the channel on which the downlink 
message is expected (see annex A). If the MS supports the napping procedure (see clause 23.4.8), the LLC shall inform 
the MAC whether any of those timers are currently running, using the TMC-CONFIGURE request primitive. The LLC 
timers that are defined in downlink signalling frames are timers T.251, T.252, T.261, T.263 and T.265. 

22.3.1 .7 Formatter protocol 

The sending formatter controls the transmission order of the LLC PDUs. It delivers LLC PDUs to the MAC 
conceivably according to the optional priority order of the PDUs using TMA-UNITDATA request primitives. The 
receiving formatter identifies LLC PDU headers in the MAC TMA-UNITDATA indication primitives and delivers the 
PDUs to the corresponding LLC entities. 

NOTE: PDU priority is considered as an optional feature and it applies to all LLC data sending entities. 

22.3.1 .7.1 MS formatter receiving entity 

Upon reception of a TMA-UNITDATA indication primitive the formatter shall decode the PDU type (and 
supplementary PDU subtype when appropriate). The formatter shall route the corresponding PDU according to the PDU 
type, endpoint identifier and address (and supplementary PDU subtype and advanced link number when appropriate) to 
the appropriate LLC protocol sub-entity instance. If the formatter recognizes a PDU which is not valid for the current 
composition of LLC entities, then the formatter shall discard the PDU without any further actions. 

22.3.1 .7.2 MS formatter sending entity 

The LLC shall indicate to the MAC the availability of data to be transmitted with the DATA_IN_BUFFER signal, 
which specifies: 

• the total amount of all outstanding data of all LLC sub-entities (including pending acknowledgements) that the 
LLC has ready to send with the specified address on the channel corresponding to the specified endpoint 
identifier; 

• the highest stealing permission for that data; 

• the highest PDU priority for outstanding unscheduled data that the LLC has ready to send with the specified 
address on the channel corresponding to the specified endpoint identifier; 

• if the MS is on a D8PSK or QAM channel: the subdivision into data categories of the outstanding data that the 
LLC has ready to send with the specified address on the channel corresponding to the specified endpoint 
identifier; 

• if the MS supports data priority: 

the maximum data priority for the outstanding data to be sent with the specified address on the channel 
corresponding to the specified endpoint identifier; 

a parameter indicating whether or not the next PDU expected to be sent with the specified address on the 
channel corresponding to the specified endpoint identifier contains packet data; 

if the MS is on a 7i/4-DQPSK channel: the subdivision into data priorities of the outstanding data to be 
sent with the specified address on the channel corresponding to the specified endpoint identifier; 

if the MS is on a D8PSK or QAM channel: the subdivision into data categories and data priorities of the 
outstanding data to be sent with the specified address on the channel corresponding to the specified 
endpoint identifier; 
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• a parameter indicating whether all, some or none of the outstanding data that the LLC has ready to send with 
the specified address on the channel corresponding to the specified endpoint identifier is fully scheduled, and 
the lowest value of the maximum schedule interval for any outstanding fully scheduled data; and 

• the highest PDU priority for outstanding fully scheduled data that the LLC has ready to send with the specified 
address on the channel corresponding to the specified endpoint identifier. 

NOTE: When indicating the maximum data priority and the amount of outstanding data for each data priority, the 
LLC may include all data in its queue for the specified address and endpoint identifier (including data that 
is not yet ready to be sent). 

In the case of an emergency message the formatter should deliver the corresponding DATA_IN_BUFFER signal to the 
MAC before a possible TMA-CANCEL request primitive so that MAC could make a new reservation request during 
the cancel process. 

Upon reception of MAC-READY from the MAC, the LLC shall decide which of the outstanding PDUs have to be sent, 
depending on the protocol needs and the size of the next MAC block. Within the same service, acknowledgements shall 
be sent prior to any data PDUs. Acknowledged basic link PDUs shall be sent before unacknowledged basic link and 
advanced link PDUs (subject to the window size of 1 for the acknowledged basic link) unless the PDU priority of the 
unacknowledged basic link or advanced link PDUs is higher than the PDU priority of the acknowledged basic link 
PDUs. Layer 2 signalling PDUs shall be sent before basic link and advanced link PDUs unless the PDU priority of the 
basic link or advanced link PDUs is higher than the PDU priority of the layer 2 signalling PDUs. L2-DATA-PRI0RITY 
PDUs shall be sent before other layer 2 signalling PDUs. 

The LLC shall deliver the PDU to the MAC using a TMA-UNITDATA request primitive containing the handle to the 
request parameter from the corresponding TL-service primitive for further referencing; in the case of a layer 2 
signalling PDU, the LLC shall include a handle to the request parameter for further referencing. 

There may be multiple MAC-READY and TMA-UNITDATA request exchanges, if the MAC is performing an 
association of LLC PDUs into one MAC block. 

If the MS is on a D8PSK channel, the first MAC -READY signal indicates the available size of the MAC block for each 
data category. (For example, advanced link segments may be of different size, depending on whether the MAC 
considers that 7i/4-DQPSK or 71/8-D8PSK modulation would currently be appropriate for first transmissions of segments 
for this data category.) Any further MAC -READY signals for a MAC block also indicate any restrictions on the data 
categories for which an LLC PDU may be sent as the second or subsequent PDU in the MAC block; the LLC should 
use this information as an additional criterion when deciding which of the outstanding PDUs to send. 

If the MS is on a QAM channel, the MAC-READY signal indicates the normal advanced link segment size. After the 
first MAC -READY signal, any further MAC -READY signals for a MAC block also indicate any restrictions on the 
data categories for which a normal data segment or other LLC PDU may be sent as the second or subsequent PDU in 
the MAC block. (In the case of a MAC block in a subslot, the first MAC-READY signal also indicates any restrictions 
on the data categories for which a normal advanced link data segment may be sent as the first PDU in the MAC block.) 
The LLC should use this information as an additional criterion when deciding which of the outstanding PDUs to send. 

The MAC will select the relevant means to transfer the information, i.e. either by random or reserved access or frame 
stealing, as appropriate based on the selected PDU priority and stealing permission parameter. 

If the MS is on a D8PSK or QAM channel, the MAC will also select the appropriate modulation level (and coding rate 
for QAM) to use for reserved access, based on the data category indicated in the TMA-UNITDATA request 

primitive(s). 

22.3.1 .7.3 Combination PDUs on D8PSK or QAM channel 

Three LLC PDUs are defined with combined functions: 

• on a D8PSK or QAM channel, AL-X-ACK and AL-X-RNR PDUs sent by both the MS and BS may optionally 
include link adaptation feedback information in addition to the usual acknowledgement information; 

• on a D8PSK or QAM channel, the L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITY PDU 
may be used for the MS to send link adaptation feedback information and residual data priority within a single 
PDU. 
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According to the protocol model, the combining for sending is performed by the LLC upon reception of the 
MAC-READY signal from the MAC; the separation on reception is performed by the formatter receiving entity. 

NOTE: This does not imply any specific implementation. In an implementation, the combining and/or separation 
may be performed using other equivalent methods. 

22.3.1 .7.3.1 MS formatter receiving entity for combination PDUs 

Upon reception of a TMA-UNITDATA indication primitive, the formatter shall decode the PDU type (and 
supplementary PDU subtype when appropriate) - as defined in clause 22. 3. 1.7. L If the PDU is an AL-X-ACK or 
AL-X-RNR PDU PDU and the link feedback information flag is set to 1, the formatter shall construct an 
L2-LINK-FEEDBACK-INF0 PDU from the "link feedback information" information element. It shall then route each 
PDU (AL-X-ACK or AL-X-RNR and L2-LINK-FEEDBACK-INFO) to the appropriate LLC protocol sub-entity 
instance for that PDU. 

22.3.1 .7.3.2 MS formatter sending entity for combination PDUs 

Upon reception of MAC-READY from the MAC, the LLC shall decide which of the outstanding PDUs have to be sent, 
depending on the protocol needs and the size of the next MAC block - as defined in clause 22.3.1.7.2. The LLC may 
then check whether combining of PDUs is appropriate as follows: 

a) If the PDU to be sent is an L2-LINK-FEEDB ACK-INFO PDU, the LLC may look through the outstanding 
PDUs for that endpoint identifier and address. If the LLC finds an AL-X-ACK or AL-X-RNR PDU, and 
assesses that a combined PDU could be sent in the MAC block without the combining causing fragmentation, 
it may construct and send a combined PDU i.e. an AL-X-ACK or AL-X-RNR PDU with the link feedback 
information flag set to 1 and with the link feedback information from the L2-LINK-FEEDB ACK-INFO PDU 
included in the "link feedback information" information element. 

b) If the PDU to be sent is an AL-X-ACK or AL-X-RNR PDU, the LLC may look through the outstanding PDUs 
for that endpoint identifier and address. If the LLC finds an L2-LINK-FEEDB ACK-INFO PDU, and assesses 
that a combined PDU could be sent in the MAC block without the combining causing fragmentation, it may 
construct and send a combined PDU i.e. an AL-X-ACK or AL-X-RNR PDU with the link feedback 
information flag set to 1 and with the link feedback information from the L2-LINK-FEEDBACK-INFO PDU 
included in the "link feedback information" information element. 

c) If the PDU to be sent is an L2-DATA-PRIORITY PDU containing no data priority blocks, the LLC may look 
through the outstanding PDUs for that endpoint identifier and address. If the LLC finds an 
L2-LINK-FEEDBACK-INFO PDU, and assesses that a combined PDU could be sent in the MAC block 
without the combining causing fragmentation, it may construct and send a combined PDU i.e. an 
L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITYPDU. 

The LLC shall deliver the combined PDU to the MAC using a TMA-UNITDATA request primitive containing an 
appropriate handle for further referencing (and using the higher of the two PDU priorities if they are different). On 
receipt of a TMA-REPORT indication primitive for that handle, the formatter shall generate two TMA-REPORT 
indication primitives containing the same "Report" parameter - one for each of the original PDUs. 

EXAMPLE: For example, in case c), on receipt of a TMA-REPORT indication primitive indicating successful 
complete transmission by random access, the formatter generates a TMA-REPORT indication 
primitive indicating successful complete transmission by random access for each of the constituent 
PDUs. Then, as defined in clause 22.3.7.1, the LLC generates equivalent TLE-REPORT indication 
primitives to the MAC independently for each of the PDUs. 

22.3.1.8 Data priority 

Clauses 22.3.1.8.1, 22.3.1.8.2, 22.3.1.8.3 and 22.3.1.8.4 shall be applicable only to MSs which support data priority. 
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22.3.1.8.1 General 



Data priority enables the MS to indicate a priority for obtaining reserved slots when it is sending packet data. For 
example, this permits the BS to grant slots to an MS with high data-priority PDUs to send ahead of other MSs with 
lower data-priority PDUs to send on the same channel. 

NOTE: Data priority is distinct from PDU priority. PDU priority affects the MS's queue re-ordering in the LLC 
and the MS's random access procedure. Data priority principally affects the BS's criteria for slot granting 
on a shared packet data channel, but is also used for queue re-ordering in the LLC. 

The SNDCP in an MS that uses data priority either regards the "MS default data priority" as being the "network default 
data priority" indicated by the SwMI or may negotiate a specific MS default data priority with the SwMI (see 
clause 28.3.5.5). In either case, the MS default data priority is a data priority which the BS applies by default to all 
reservation requirements indicated by that MS on a packet data channel. 

Also, when the SNDCP sends each packet data PDU, it includes the data priority for that PDU within the primitive 
issued to the lower layers; the data priority parameter is set to one of the eight defined values of data priority (0 to 7) for 
data that is not scheduled or contains the value "undefined" in the case of scheduled data. This information enables the 
DLL in the MS to request short-term variations to the default data priority: 

• the LLC collates the information on data priorities for TL-SDUs and LLC PDUs, and issues it to the MAC in 
the DATA_IN_BUFFER signal; 

• when appropriate, the MAC sends an L2-DATA-PRI0RITY message if it wishes to indicate a short-term 
variation to the default data priority - either indicating a single short-term data priority or indicating the current 
requirements for multiple data priorities (see clause 23.4.7); the L2-DATA-PRI0RITY message is a layer 2 
signalling message, so the MAC issues it to the LLC in a TLE-UNITDATA request primitive; 

• the LLC sends the message using the procedures defined in clause 22.3.7. 1 . 

The LLC also indicates to the MAC whether it currently expects that the next PDU to be sent will contain packet data. 
(This may affect the MAC criteria for initiating the random access procedure.) 

22.3.1 .8.2 Sending order of TL-SDUs 

Packet data TL-SDUs to be sent on a channel are sent using the unacknowledged basic link for that channel or using an 
advanced link. The data priority of each packet data TL-SDU is indicated by the service user in the TL-DATA request 
primitive for an advanced link and in the TL-UNITDATA request primitive for the basic link (except in the case of 
scheduled data). 

If the MS supports data priority, and the MS default data priority last provided by the higher layers in the 
TL-CONFIGURE request primitive contained one of the eight defined values (i.e. was not set to "not applicable"), then 
the LLC shall modify the sending order of packet data TL-SDUs to be sent on a channel (using the unacknowledged 
basic link or any advanced link) as follows: 

• the LLC shall order the packet data TL-SDUs according to the PDU priority; 

• the LLC shall order the packet data TL-SDUs within one PDU priority according to the data priority. 

It is recommended that, within one PDU priority and data priority, the LLC sends unacknowledged basic link packet 
data TL-SDUs before advanced link packet data TL-SDUs. 

When the higher layers issue scheduled data to the LLC (see clause 22.3.1.9), the data priority parameter in the 
TL-DATA or TL-UNITDATA request primitive is set to "undefined". The data priority parameter may have a defined 
value for initial scheduled data. For the purposes of the ordering of packet data TL-SDUs, the LLC should: 

• regard scheduled data TL-SDUs as having data priority higher than 6 i.e. as having a data priority 
equivalent to "6,5"; 

• regard initial scheduled data TL-SDUs with "undefined" data priority as having data priority "6,5"; 

• regard initial scheduled data TL-SDUs with a defined data priority as having data priority equal to the 
maximum of "6,5" and the defined data priority. 
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NOTE 1: The definition of assumed data priority of "6,5" for scheduled data and initial scheduled data in these 

three points applies only for the purposes of LLC ordering of packet data TL-SDUs. It is not used when 
collating data priority information to provide to the MAC (see clause 22.3. L8. 3); the value of the data 
priority parameter in the TL-DATA or TL-UNITDATA request primitive (i.e. value "undefined" for 
scheduled data) applies in clause 22.3. L8. 3. 

If already-started TL-SDUs being sent on an advanced link have lower PDU priority or data priority than an unstarted 
TL-SDU to be sent on that advanced link then, for the purposes of the ordering of packet data TL-SDUs, the LLC 
should promote those already-started TL-SDU(s) as follows: 

• if already-started TL-SDU(s) being sent on an advanced link have lower PDU priority than an unstarted 
TL-SDU to be sent on that advanced link then, for the purposes of the ordering of packet data TL-SDUs, the 
LLC should promote those already-started TL-SDU(s) to the higher PDU priority; and 

• if already-started TL-SDU(s) being sent on an advanced link have lower data priority, and have the same or 
lower PDU priority, than an unstarted TL-SDU to be sent on that advanced link then, for the purposes of the 
ordering of packet data TL-SDUs, the LLC should promote those already-started TL-SDU(s) to the higher data 
priority. 

NOTE 2: Thus already-started and unstarted TL-SDUs for an advanced link with high maximum priority are sent 
before already-started (and unstarted) TL-SDUs for other advanced links with lower maximum priority; 
they are also sent before unacknowledged basic link packet data with lower maximum priority. 

NOTE 3: The LLC may vary the sending order of TL-SDUs from the order defined above if there are temporary 

constraints on which TL-SDUs may be sent, for example, if the window of an advanced link is full or, on 
a D8PSK or QAM channel, if there are restrictions on the data categories for which an LLC PDU may be 
sent as the second or subsequent PDU in a MAC block. 

NOTE 4: The LLC may choose not to fill up the advanced link sending window or may restrict the amount of data 
in the sending window if it expects that the higher layers may wish to send higher priority PDUs than 
those currently in the window. The criteria that the LLC uses to decide whether to restrict the number of 
TL-SDUs in the advanced link sending window are outside the scope of the present document. 

There are other types of TL-SDUs and LLC PDUs that may need to be sent on the channel: 

a) TL-SDUs to be sent using the acknowledged basic link; 

b) TL-SDUs that do not contain packet data, and are to be sent using the unacknowledged basic link or an 
advanced link; 

c) AL-SETUP, AL-RECONNECT and AL-DISC PDUs; 

d) layer 2 signalling PDUs; and 

e) basic link and advanced link acknowledgements. 

These TL-SDUs and LLC PDUs have a PDU priority but do not have a data priority. The LLC should choose an 
appropriate ordering, subject to the constraints given in clause 22.3. L7. 2. 

EXAMPLE: In cases a), b), c) and d), the TL-SDU or LLC PDU may be sent ahead of packet data irrespective 
of the PDU priority, or may be included in the packet data ordering per PDU priority (ahead of the 
packet data with that PDU priority). 

In case e), clause 22.3. L7.2 requires that, within the same service, acknowledgements are sent 
prior to any data PDUs. 

NOTE 5: In cases a), b), c) and d), it is recommended that TL-SDUs and LLC PDUs with PDU priority 2 or more 
are at least sent ahead of packet data with PDU priority 6; they may be sent ahead of packet data with 
PDU priority 7. Also TL-SDUs and LLC PDUs with PDU priority or 1 may be sent ahead of packet 
data irrespective of PDU priority. 
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22.3.1 .8.3 Providing data priority information to the MAC 

If the MS supports data priority then, as described in clause 22.3.1.7.2, the DATA_IN_BUFFER signal shall indicate 
the maximum data priority for the outstanding data to be sent with the specified address on the channel corresponding to 
the specified endpoint identifier, and the subdivision of that outstanding data into data priorities (and data categories if 
the MS is on a D8PSK or QAM channel). 

NOTE 1 : When indicating the maximum data priority and the amount of outstanding data for each data priority, the 
LLC may include all data in its queue for the specified address and channel (including data that is not yet 
ready to be sent). 

The LLC shall generate the information as follows. 

The data priority of each TL-SDU is generally indicated by the service user in the TL-DATA request primitive for the 
advanced link and in the TL-UNITDATA request primitive for the basic link; in some cases the data priority parameter 
may contain the value "undefined" (for example, for scheduled data). In the case of a TL-DATA request primitive for 
the advanced link, the LLC shall regard the specified data priority as applying to the first transmission of segments of 
the TL-SDU and to any segment re-transmissions. In the case of a TL-UNITDATA request primitive for the basic link, 
the LLC shall regard the specified data priority as applying to all N.253 + 1 transmissions of the TL-SDU. 

The LLC shall regard TL-SDUs to be sent on the acknowledged basic link as having "undefined" data priority. It shall 
also regard PDUs not containing a TL-SDU or TL-SDU segment as having "undefined" data priority (e.g. LLC 
acknowledgements, AL-SETUP, AL-RECONNECT, AL-DISC and layer 2 signalhng PDUs). 

If the LLC queue for an address and channel contains TL-SDUs with different defined data priorities or a mixture of 
defined data priorities and "undefined" data priority, the LLC should modify the data priorities as follows - after any 
re-ordering of the sending order of TL-SDUs and LLC PDUs. When a TL-SDU with defined data priority DPRI 
(denoted TL-SDUn) is in the LLC queue (either already started or waiting to be sent): 

• any data with lower data priority and preceding TL-SDUn in the LLC queue for that address and channel 
(either already started or waiting to be sent) should be promoted to data priority DPRI; 

• any data with undefined data priority and preceding TL-SDUn in the LLC queue for that address and channel 
(either already started or waiting to be sent) should be promoted to data priority DPRI, except that any 
L2-DATA-PRIORITY PDU should retain data priority value "undefined". 

Any data with undefined data priority, not preceding data with defined data priority, should retain data priority value 
"undefined". In particular, if there is no data with defined data priority in the LLC queue, then all data in the LLC queue 
retains data priority value "undefined" and the LLC shall set the maximum data priority parameter in the 
DATA_IN_BUFFER signal to "undefined". 

NOTE 2: In an implementation, this process may be performed by initializing a "maximum data priority 

encountered so far" parameter to a null value of "undefined" and working forwards, keeping a record of 
the maximum data priority encountered so far (where any defined data priority is regarded as higher than 
the undefined data priority for the purposes of this process). Any data with undefined data priority (except 
the L2-DATA-PRI0RITY PDU), or with lower data priority than the maximum data priority encountered 
so far, is promoted to the maximum data priority encountered so far. 

After performing this process, if a TL-SDU that does not contain packet data has PDU priority 7 and has data priority 
less than 7, the LLC may promote that TL-SDU to data priority 7. 

The LLC shall then collate the resulting modified data priority information and pass it to the MAC in the 
DATA_IN_BUFFER signal. 

The LLC shall also indicate to the MAC (using the DATA_IN_BUFFER signal) whether or not it currently expects that 
the next PDU to be sent with the specified address on the channel corresponding to the specified endpoint identifier will 
contain packet data. 
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22.3.1 .8.4 Sending of L2-DATA-PRI0RITY PDU 

When the LLC receives a TLE-UNITDATA request primitive from the MAC requesting sending of an 
L2-DATA-PRIORITY PDU, the LLC shall send the PDU using the procedures defined in clause 22.3.7.1. 

When the MAC issues the TLE-UNITDATA request primitive, it sets the PDU priority to the highest PDU priority 
indicated in the DATA_IN_BUFFER signal (see clause 23.4.7) so that, on reception of the next MAC -READY signal, 
the LLC will normally send the L2-DATA-PRI0RITY PDU (issuing the PDU to the MAC using a TMA-UNITDATA 
request primitive). 

22.3.1.9 Scheduled data 

When the LLC in an MS receives a TL-DATA request primitive for the advanced link, or a TL-UNITDATA request 
primitive for the basic link, the "scheduled data status" parameter in the primitive indicates whether the TL-SDU should 
be treated as: 

• not scheduled data (i.e. if the data is not for a schedule); or 

• initial scheduled data (i.e. for the first TL-SDU of a schedule or after a substantial gap in use of the schedule); 
or 

• scheduled data (i.e. for subsequent TL-SDUs of a schedule). 

See also clause 28. For scheduled data, the primitive also indicates the maximum schedule interval for this schedule. 

As described in clause 22.3. L7.2, the DATA_IN_BUFFER signal from the LLC to the MAC indicates whether all, 
some or none of the outstanding data for the specified address and channel is "fully scheduled", and the lowest value of 
the maximum schedule interval for any outstanding "fully scheduled" data; it also indicates the maximum PDU priority 
for outstanding "unscheduled" and "fully scheduled" data. When generating this information, the LLC shall convert 
from the information in the "scheduled data status" parameter to the information about "fully scheduled" and 
"unscheduled" data in the buffer as follows: 

• in the case of initial scheduled data sent by acknowledged transfer on an advanced link, the LLC shall regard 
the first transmission of the TL-SDU and any segment re-transmissions as unscheduled; 

• in the case of initial scheduled data sent by unacknowledged data transfer on the basic link, the LLC shall 
regard all N.253 + 1 transmissions of the TL-SDU as unscheduled; 

• in the case of scheduled data sent by acknowledged transfer on an advanced link, the LLC shall regard the first 
transmission of the TL-SDU as fully scheduled and should regard any segment re-transmissions as 
unscheduled; 

• in the case of scheduled data sent by unacknowledged data transfer on the basic link, the LLC shall regard all 
N.253 + 1 transmissions of the TL-SDU as fully scheduled; 

• the LLC shall regard all other types of data and signalling as unscheduled. 

NOTE: The MAC uses the information about "fully scheduled" and "unscheduled" data in the buffer to decide 
when to initiate the random access procedure. 

22.3.1.10 Data category 

When on a D8PSK or QAM channel, the MAC selects the appropriate modulation level (and coding rate for QAM) to 
use when sending TM-SDUs by reserved access, based on the link conditions and the data category parameter in the 
TMA-UNITDATA request primitive(s). 

The data category parameter is provided by the LLC in the TMA-UNITDATA request primitive (partly derived from 
the data class information parameter from the higher layers). It may be used to indicate information about the type of 
data in the TM-SDU and the required reliability level for the transmission - enabling the MAC to make decisions about 
the modulation level (and coding rate for QAM) to use when sending the TM-SDU. The implementer should choose an 
appropriate definition of the data category parameter for the chosen link adaptation algorithm. 
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For example, the data category parameter may indicate whether the data in the TM-SDU is: 

background class data - reliability level 1 ; or 

background class data - reliability level 2; or 

background class data - reliability level 3; or 

telemetry class data - reliability level 1 ; or 

telemetry class data - reliability level 2; or 

telemetry class data - reliability level 3; or 

real-time class data; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 1; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 2; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 3. 

NOTE 1: In this example of possible data categories, it is intended that reliability level 3 refers to better (i.e. higher) 
reliability than reliability level 2, and reliability level 2 refers to better (i.e. higher) reliability than 
reliability level 1 . 

NOTE 2: In this example of possible data categories, three reliability levels are used for background class data, 
telemetry class data and non-classified data. In an implementation, fewer than three reliability levels 
could be used if preferred. For instance, if preferred, two reliability levels could be used for background 
class data and/or telemetry class data and/or non-classified data. 

NOTE 3: The MAC uses both the data class and the reliability level when it selects the appropriate modulation 

level (and coding rate for QAM). For example, the appropriate modulation level (and/or coding rate for 
QAM) for "telemetry class data - reliability level 1" may be different from that for "background class data 
- reliability level 1 " . 

When indicating the required reliability level for the transmission, it is recommended that: 

a) TL-SDUs sent by acknowledged data transfer on the basic link should be sent using a high reliability for all 
transmissions. 

b) Basic link acknowledgements should be sent using a high reliability for all transmissions. 

c) AL-SETUP, AL-RECONNECT and AL-DISC PDUs should be sent using a high reliability for all 

transmissions. 

d) Advanced hnk acknowledgements (AL-ACK, AL-RNR, AL-X-ACK and AL-X-RNR) should be sent using a 
high reliability for all transmissions. 

NOTE 4: Thus, in the example of possible data categories, items a), b), c) and d) could be sent using "non-classified 
data - reliability level 3" for all transmissions. 

e) Layer 2 signalling PDUs sent on request of the MAC should be sent using the data category indicated by the 
MAC in the TLE-UNITDATA request primitive. 

NOTE 5: In the example of possible data categories, when the MAC issues the TLE-UNITDATA request primitive, 
it could indicate non-classified data with either reliability level 1, 2 or 3 depending on the required 
reliability of the information in the layer 2 signalling message. For example, reliability level 1 could be 
used when the layer 2 signalling message may be sent using the same modulation level and coding rate as 
any ongoing packet data, whereas reliability levels 2 and 3 could indicate a requirement for higher 
reliability. 
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f) When a segment has been sent a number of times on an acknowledged advanced Hnk, further retransmissions 
of that segment should be sent using a higher reliability. So, for example, for background class data or 
telemetry class data, if using three reliability levels, the MS (or BS) could use reliability level 1 for the first 
one or more transmissions of advanced link segments (enabling higher throughput when successful), then use 
reliability level 2 for the next one or more retransmissions of segments (if retransmissions are needed) and 
then revert to reliability level 3 for a segment either: 

when the segment has been sent a specific number of times without success; and/or 

when only a specific number of retransmissions remain before the maximum number of segment 
retransmissions N.274 of that segment is exceeded. 

At least the last two possible retransmissions of a segment before the maximum number of segment 
retransmissions N.274 of that segment is exceeded should be sent using a high reliability. 

NOTE 6: In the example of possible data categories, the maximum number of segment transmissions using 
reliability level 1 (and/or reliability level 2) may depend on the maximum number of segment 
retransmissions N.274 for that advanced link. 

In an implementation, the maximum number of segment transmissions using reliability level 1 (and/or 
reliability level 2) may also vary according to the current channel conditions, based on information 
provided to the LLC by the MAC. 

When appropriate, the MS (or BS) may revert to using fewer than three reliability levels. 

NOTE 7: As indicated in point f), it is expected that, for acknowledged packet data, the reliability level may vary 
for transmissions of one segment according to the number of times that segment has been transmitted, 
starting with low reliability and increasing to higher reliability if the first transmission(s) of that segment 
are not successful. This contrasts with non-classified data (items a) to e)) for which the type of 
information may determine the reliability level for all transmissions of that PDU. 

22.3.2 Basic link procedures 

The basic link shall offer two services, acknowledged and unacknowledged data transfer. The acknowledged service 
supports also a data response service primitive for call set-up optimization. The data with the response primitive is 
transmitted using an acknowledge message without an explicit acknowledgement, see clause 22.2. LL 

The basic link LLC protocol of the MS is modelled by two processes, BL_LLC_MS and Formatter, the latter being 
common with the advanced links and layer 2 signalling, refer to figure 22.2. 

The present document models the numbering of TL-SDUs and acknowledgements and local function indicators by local 
variables. Each basic link shall employ separate sets of variables, parameters and timers. At the sending side variables 
and main parameters are: 

• N(S) TL-SDU number in the sent data PDUs; 

• N(R) TL-SDU number in the received acknowledgement PDUs; 

• V(S) the next TL-SDU number to be sent or to be re-sent; 
and at the receiving side: 

• N(S) TL-SDU number in the received data PDUs; 

• N(R) TL-SDU number in the sent acknowledgement PDUs; 

• V(R) the last received TL-SDU number. 
Timers and constants are defined in annex A. 

NOTE: This protocol description is valid for one basic link, which uses one address. 
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22.3.2.1 Establishment of information transfer in basic link 

No explicit establishment is required for the basic link. At least one basic link shall be available, when the MS is 
synchronized to a BS. When there is no advanced link nor circuit mode connection, then there is a single basic link on 
the corresponding control channel. When there are any defined advanced links or circuit mode connections, then there is 
one basic link per each advanced link and circuit mode connection. If an advanced link uses the same physical resource 
allocations as a circuit mode connection, then there is only one basic link associated with the pair. If multiple advanced 
links use the same physical resource, then there is only one basic link associated with those multiple advanced links. 

The MS shall keep all basic links that are not removed in the physical resource allocation, if the MS is capable of 
operation on concurrent channels, see clause 23. The BS may allocate e.g. the first advanced link and the basic Unk 
associated to a circuit mode call so that the previous basic link on the initiating control channel is released. 

After power-on or in the first transmission, when roaming or migrating to a new BS, the MS LLC shall start TL-SDU 
numbering from "0" by setting local variable V(S) = 0. 

22.3.2.2 Quality of service selection 

The service user shall define the quality of service for each message by selecting a basic link and the primitive type 
either TL-DATA request or TL-UNITDATA request and by selecting the parameters in that primitive, see definition of 
parameters in clause 20. The undetected message error rate shall be defined by selecting the use of the FCS. The 
TL-SDU sending order in the selected basic link and in relation to any concurrent advanced link(s) and layer 2 
signalling shall be defined by the conceivably requested PDU priority, which may change the transmission order of 
TL-SDUs. The PDU priority shall affect the transmission of a already started TL-SDU sending only if the highest 
priority (emergency) is used and the sending of the current TL-SDU is destroyed by cancellation. 

NOTE: The maximum data transfer throughput of an associated basic link is defined by the associated advanced 
link(s) or circuit mode call. 

22.3.2.3 Acknowledged data transmission in basic link 

The acknowledged data transmission is modelled by the states in the sending process: 

• TX_READY transmitter is ready to send next TL-SDU; 
and in the receiving process: 

• RX_READY receiver is ready to receive data from the MAC. 

Each acknowledged information transfer is identified by a TL-SDU number N(S) both in BL-DATA and BL-ADATA 
PDUs. The acknowledgement contains the number N(R) of the correctly received TL-SDU both in BL-ACK and 
BL-ADATA PDUs. In addition, the receiver has the possibility to send data in a TL-DATA response primitive together 
with the acknowledgement without a sequence number. The N(R) in that acknowledgement marks the TL-SDU sent 
using an acknowledgement BL-ACK PDU. 

The LLC process may receive: 

• service user service primitive: 

a) a TL-DATA request primitive (handle to the request) and then the LLC shall: 

i) issue an immediate TL- REPORT indication primitive confirming the handle to the request 
parameter; 

ii) calculate FCS, when requested, and append it to TL-SDU; 

iii) place the TL-SDU into transmission buffer according to the indicated PDU priority; 

iv) indicate new data in the transmitting buffer to the formatter using DATA_IN_BUFFER signal; 
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v) in the case of a TL-D ATA request primitive with the emergency priority and if there is an ongoing 
lower priority TL-D ATA (or TL-UNITDATA) PDU in transmission on that basic link at the MAC 
layer, then the LLC may deliver a TMA-CANCEL request primitive via formatter to the MAC, see 
clause 22.3.1.4. The LLC shall not cancel a BL-ACK PDU with or without service user data. The 
LLC may cancel a BL-ADATA PDU and memorize the N(R) in it. 

b) a TL-D ATA response primitive to the TL-D ATA indication primitive (handle to the request) before the 
corresponding acknowledgement is sent and then the LLC shall: 

i) calculate PCS, when requested, and append it to TL-SDU; 

ii) format a BL-ACK PDU (N(R) = V(R)) with the (optional) TL-SDU from the TL-D ATA response 
primitive; 

iii) inform the formatter using DATA_IN_BUFFER signal. 

c) a TL-D ATA response primitive (handle to the request) after sending the corresponding BL-ACK or 
BL-ADATA PDU, then the LLC shall: 

i) issue an immediate TL-REPORT indication primitive confirming the handle to the request 
parameter (from the TL-D ATA response primitive) as if it has received a TL-D ATA request 
primitive; 

ii) calculate PCS, when requested, and append it to TL-SDU; 

iii) place the TL-SDU into transmission buffer according to the indicated PDU priority; 

iv) indicate new data in the transmitting buffer to the formatter using DATA_IN_BUPPER signal; 

v) in the case of a TL-D ATA response primitive with emergency priority and if there is an ongoing 
lower priority TL-D ATA (or TL-UNITDATA) PDU in transmission on that basic link at the MAC 
layer, then the LLC may deliver a TMA-CANCEL primitive via formatter to the MAC, see 
clause 22.3.1.4. The LLC shall not cancel a BL-ACK PDU (which in this situation should be 
without user data). 

local indications: 

d) a MAC-READY indication from the formatter and then: 

if a BL-ACK PDU is ready due to a TL-D ATA response primitive, then the LLC shall issue it to 
the formatter with an acknowledgement number N(R) = V(R); 

if there is a waiting acknowledgement and a TL-D ATA request primitive available, then the LLC 
shall: 

i) set N(S) = V(S) for the TL-SDU to be sent; 

ii) set N(R) = V(R) for the waiting acknowledgement; 

iii) form the corresponding BL-ADATA PDU and issue it to the formatter; 

if the size of the TL-D ATA plus the size of the BL-ADATA LLC header exceeds the size of the 
TM-SDU in this MAC block, then the LLC shall issue a BL-ACK PDU with an acknowledgement 
number N(R) = V(R) to the formatter without any service user data and send the TL-SDU using 
BL-DATA PDU; 

if there is a waiting acknowledgement and neither a TL-D ATA response nor a TL-D ATA request 
primitive available, then the LLC shall issue a BL-ACK PDU with an acknowledgement number 
N(R) = V(R) to the formatter without any service user data; 

if there is no waiting acknowledgement but a TL-SDU is available, then the LLC shall set 

N(S) = V(S) for the TL-SDU to be sent, form the corresponding BL-DATA PDU and issue it to the 

formatter. 

e) a TMA-REPORT indication primitive confirming the handle to the request parameter; 
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f) a TMA-REPORT indication primitive (one of the complete TM-SDU transmission indications) and if it 
is due to a PDU which contained service user data in either a BL-DATA or BL-ADATA PDU and the 
PDU transmission was successful and complete transmission by random access or complete transmission 
by reserved access or stealing, then the LLC shall start the re-try timer T.251; and in any case, if this is 
the first transmission of the TL-SDU, then the LLC shall issue a TL-REPORT indication primitive (first 
complete transmission) to the service user; 

g) a TMA-REPORT indication primitive (random access failure) and if it is due to a PDU which contained 
service user data, then the LLC shall inform the service user of unsuccessful transmission by 
TL-REPORT primitive (failed transfer), and delete the corresponding TL-SDU from the sending buffer. 
If the report was due to a BL-DATA or BL-ADATA PDU, the LLC shall increment V(S); 

h) a TMA-REPORT indication primitive (fragmentation failure) and: 

if it is due to a BL-ACK PDU, then the LLC shall discard the optional TL-SDU; 

if the report is due to a BL-DATA or BL-ADATA PDU and the number of allowed retransmissions 
N.252 of the corresponding TL-SDU is not exceeded, then the LLC shall keep the TL-SDU for 
re-transmission and inform the formatter by a DATA_IN_BUFFER signal; or 

otherwise the LLC shall inform the service user of unsuccessful transmission by TL-REPORT 
primitive (failed transfer), increment V(S) and delete TL-SDU from the sending buffer. 

i) re-try timer T.251 expires and 

if the number of allowed retransmissions N.252 is not exceeded, then the LLC shall keep the 
TL-SDU in the sending buffer for re-transmission and inform the formatter by a 
DATA_IN_BUFFER signal; or 

otherwise the LLC shall inform the service user of unsuccessful transmission by TL-REPORT 
primitive (failed transfer), increment V(S) and delete TL-SDU from the sending buffer; 

PDU from the peer entity: 

j) a BL-ACK and then: 

if there is a TL-SDU waiting for a re-transmission in the sending buffer, then: 

if the TL-SDU number (in the BL-ACK PDU) N(R) = V(S), then the LLC shall confirm the 
success of the transmission to the service user by a TL-DATA confirm (successful transfer) 
primitive and deliver the contained TL-SDU, if any upon condition that the ECS calculation is 
successful in case the optional ECS is used, increment V(S), delete the TL-SDU waiting for a 
re-sending from the sending buffer and stop the re-try timer T.251; or 

if the TL-SDU number (in the BL-ACK PDU) N(R) is not equal to V(S), then the LLC shall deliver 
contained TL-SDU, if any upon condition that the ECS calculation is successful in case the optional 
ECS is used, using TL-DATA indication primitive; and 

if the number of allowed retransmissions N.252 of the TL-SDU is not exceeded, then the LLC shall 
keep the corresponding TL-SDU in the sending buffer for re-transmission and inform the formatter 
by the DATA_IN_BUEEER signal; or 

if the number of allowed retransmissions N.252 of the TL-SDU is exceeded, then the LLC shall 
inform the service user of unsuccessful transmission by a TL-REPORT indication primitive (failed 
transfer), increment V(S), stop re-try timer T.251 and discard the corresponding TL-SDU from the 
sending buffer; 

if there is no TL-SDU waiting for a re-transmission in the sending buffer, then the LLC shall 
deliver contained TL-SDU, if any upon condition that the ECS calculation is successful in case the 
optional ECS is used, using TL-DATA indication primitive; 
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k) a BL-DATA PDU and then: 

i) the LLC shall delete the possible BL-ACK PDU from the sending buffer; 

ii) the LLC shall: 

if the FCS is used and it is correct or FCS is not used, then the LLC shall select a new handle 
to the request parameter value and deliver TL-SDU to the service user in a TL-DATA 
indication service primitive (handle to the request), memorize a waiting acknowledgement 
with number V(R) = N(S), start to wait for TL-DATA response primitive and inform the 
formatter by the DATA_IN_BUFFER signal; 

NOTE 1 : As both MLE and LLC select handle to the request parameter values and both could select the same value 
a mechanism should be implemented to prevent it such as a sub-division of the value space. 

■ if the FCS is used and it is not correct and no other not yet acknowledged data received before the 
PDU with incorrect FCS was received, then no acknowledgement is sent, i.e. LLC action against 
the received BL-DATA with incorrect FCS is as that PDU was not received. 

1) a BL-ADATA PDU and then the LLC shall separate the acknowledgement N(R) and incoming TL-SDU 
including N(S) and shall continue as if LLC had received a BL-ACK PDU (without service user data) 
first (case j) and then a BL-DATA PDU (case k). 

The LLC shall set the stealing permission parameter to "steal within time T.214" for the BL-ACK PDU in the basic link 
protocol in case the MAC currently has traffic transmit permission. The LLC should also set PDU priority level = 5 
(though this parameter will not normally be used by the MAC). 

NOTE 2: At the reception of a new BL-DATA PDU before acknowledging the previous received BL-DATA PDU 
the LLC stops all acknowledgement actions of the previous TL-SDU independently of the TL-SDU 
number N(S). 

NOTE 3: The defined protocol and PDU numbering supports the receiving peer entity to request a TL-SDU 

re-sending, but it does not guarantee alone a safe mechanism for suppression of duplicate TL-SDUs. 

NOTE 4: The transmission of a TL-SDU from a TL-DATA request primitive is totally independent of any data 

transmission in the other direction. On the other hand a TL-SDU from a TL-DATA response primitive is 
normally transferred in the corresponding acknowledgement of the TL-DATA indication primitive. If the 
TL-DATA response primitive is delayed too much, then the TL-SDU will be sent in a BL-DATA PDU 
and it will be acknowledged by a TL-DATA confirm primitive. 

NOTE 5: The random access failure prevents further TL-SDU sending re-tries and, to increase the probability to get 
an emergency message through, the MAC will use more random access re-tries for higher priority 
TL-SDUs. 

NOTE 6: The information "First complete transmission" by random access may be used in cancellation process in 
addition or in place of a request to the MAC. 

22.3.2.4 Unacknowledged data transfer in the basic link 

The procedures in an MS for unacknowledged data transfer in the basic link are described in the following clauses. 

22.3.2.4.1 Actions on TL-UNITDATA request primitive (sending entity) 

During sending of unacknowledged service user data the LLC may receive: 

a) a TL-UNITDATA request primitive (handle to the request) from the service user and then: 

the LLC may issue an immediate TL-REPORT indication primitive containing the handle to the request 
parameter to the TL-UNITDATA request primitive; 

if requested by the service user, then the LLC shall calculate and append a FCS to the SDU; 

the LLC shall store TL-SDU in priority order into the sending buffer for sending N.253 + 1 times, and 
inform formatter with the DATA_IN_BUFFER signal. 
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b) a MAC-READY from the formatter and then the LLC shall deliver the highest priority (unacknowledged 
service) TL-SDU as a BL-UDATA PDU to the formatter; 

c) a TMA-REPORT indication primitive confirming the handle to the request parameter; 

d) a TMA-REPORT indication primitive (successful complete transmission by random access), and then the LLC 
shall remove the TL-SDU from the transmitting buffer and deliver a TL-REPORT indication primitive 
(transfer completed) to the service user; 

e) a TMA-REPORT indication primitive (complete transmission by stealing or by reserved access), and if that 
TL-SDU has now been completely transmitted N.253 + 1 times, then the LLC shall remove the TL-SDU from 
the transmitting buffer and deliver a TL-REPORT indication primitive (transfer completed) to the service user; 

f) a TMA-REPORT indication primitive (failure of fragmentation process) and then: 

if N.253 > 0, the LLC shall try to re-send the TL-SDU so that there shall be at maximum N.253 + 1 
failed transmissions (in addition to the N.253 + 1 complete transmissions); if there have not been 
N.253 + 1 complete transmissions when the maximum number of failed transmissions N.253 + 1 has 
been reached, then the LLC shall remove the TL-SDU from the sending buffer and issue a TL-REPORT 
indication primitive (failed transfer) to the service user; 

if N.253 = 0, the LLC shall try to re-send the TL-SDU so that there shall be at maximum two failed 
transmissions (or the TL-SDU has been completely transmitted); if there has not been one complete 
transmission when the maximum of two failed transmissions has been reached, then the LLC shall 
remove the TL-SDU from the sending buffer and issue a TL-REPORT indication primitive (failed 
transfer) to the service user; 

g) a TMA-REPORT indication primitive (random access failure) and then the LLC shall remove TL-SDU from 
the sending buffer and issue a TL-REPORT indication primitive (failed transfer) to the service user. 

NOTE 1: The service user may indicate the required number of repetitions (i.e. N.253) in the TL-UNITDATA 

request primitive, in which case that value is applied for transmission of the TL-SDU. If the service user 
does not indicate the required number of repetitions, the value of N.253 chosen by the MS designer is 
used (see annex A). 

NOTE 2: The MS may send more than one BL-UDATA PDU in one MAC block (using MAC PDU association). 

NOTE 3: For N.253 > 0, the MS should not send the same BL-UDATA PDU more than once in one MAC block. 
The unacknowledged basic link service does not guarantee in-order delivery at the receiving entity. 
Therefore, in order to use the capacity of MAC blocks by PDU association, the MS may interleave 
retransmissions of multiple BL-UDATA PDUs. 

NOTE 4: In the DATA_IN_BUFFER signal, the LLC may include all outstanding unacknowledged basic link data 
as outstanding data ready to be sent, so that the MAC can indicate a reservation requirement for that data. 

22.3.2.4.2 Actions on BL-UDATA PDU (receiving entity) 

Upon reception of a BL-UDATA PDU from the formatter: 

i) if indicated by the received PDU, LLC shall calculate ECS and: 

if the ECS is correct, the LLC shall inform the service user of a reception of a TL-SDU using a 
TL-UNITDATA indication primitive; 

if the ECS is not correct, the LLC shall discard the SDU. 

ii) if the received PDU does not contain ECS, then the LLC shall issue the TL-SDU to the service user using a 
TL-UNITDATA indication primitive. 

NOTE: The basic link protocol does not suppress received duplicates. 



£75/ 



681 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

22.3.3 Advanced link procedures for the acknowledged service 

The LLC advanced link protocol of the MS is modelled by processes: AL_MAIN, AL_TX, AL_RX and Formatter, the 
latter being common also with the basic link and unacknowledged advanced link services and layer 2 signalling, refer to 
figure 22.2. Refer to clause 22.3.1.7 for formatter processes. 

The present document models the numbering of TL-SDUs and acknowledgements and local function indicators by local 
variables. Each advanced link shall employ separate sets of variables, parameters and timers. 

At the sending entity: 

• N(S) TL-SDU number in the sent data PDUs; 

• N(R) TL-SDU number in the received acknowledgement PDUs; 

• S(S) Segment number in the sent data PDU; 

• S(R) Segment number in the received acknowledgement PDU. 
At the receiving entity: 

• N(S) TL-SDU number in the received data messages; 

• N(R) TL-SDU number in the sent acknowledgement messages; 

• S(S) Segment number in the received data PDU; 

• S(R) Segment number in the sent acknowledgement PDU. 
Timers and constants are defined in annex A. 

In figure 22.2 the AL-MAJN controls independently the state of each advanced link. 

Each advanced link set-up, data transfer, reconnection and disconnection phase is modelled by states: 

• IDLE link is not ready for data transfer; 

• WAIT_IN_CONNECT link is in the incoming set-up phase; 

• WAIT_OUT_CONNECT link is in the outgoing set-up phase; 

• WAIT_DISCONNECT link is waiting for outgoing disconnection; 

• WAIT_RECONNECT link is waiting for reconnection; 

• CONNECTED link is ready for data transfer. 

The acknowledged information transfer in the CONNECTED state of each advanced link (N.261) is modelled by a 
single state in the sending process: 

• AL_TX_READY transmitter is ready to send the next TL-SDU; 
and respectively by a single state in the receiving process: 

• AL_RX_READY receiver is ready to receive data from the MAC. 

NOTE 1 : It is recommended that an MS which only supports 7i/4-DQPSK operation does not use fragmentation for 
sending advanced link PDUs. 

NOTE 2: If the MS supports D8PSK operation, fragmentation is needed when a segment cut for transmission using 
3I/8-D8PSK modulation is re-transmitted using 3i/4-DQPSK modulation. 
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NOTE 3: It is recommended that an MS does not normally use fragmentation for sending advanced link PDUs on a 
QAM channel. However, fragmentation may be needed in some cases. For example, after a reduction of 
bandwidth (for example, if the bandwidth changes from 50 kHz to 25 kHz), fragmentation may be needed 
for re-transmissions of segments cut for transmission on the old channel. Alternatively, the advanced link 
may be reset after a reduction of bandwidth. 

22.3.3.1 Advanced link establishment for the acknowledged service 

The service user shall set up the advanced link before any data transmission may occur. The advanced link is available 
for data transfer until the service user or the LLC entity disconnects it. The advanced link number may be used locally 
as a part of the link identifier related to an advanced hnk. The estabhshed advanced link can be used for two-way 
information transfer. 

There can be only one connection set-up in progress at the same time. If there are colliding set-ups from both peer 
entities, then those will be merged into a single set-up process. 

The service user shall define the quality of service by setting up an advanced link and later by selecting that advanced 
link for the data transmission. The quality of service parameters applicable to the LLC layer are defined in clause 20. 
The set-up report parameter shall be used to indicate the progress of the connection establishment. 

The procedures for sending and reception of the AL-SETUP PDU are defined in clauses 22.3.3.1.1, 22.3.3.1.2, 
22.3.3.1.3 and 22.3.3.1.4. The following rules also apply: 

a) The LLC should not send an AL-SETUP PDU for an extended acknowledged advanced link to an LLC that 
does not support extended advanced link(s). 

NOTE 1: BS support of extended advanced links is indicated in the "extended services broadcast" element in the 
SYSINFO and SYSINFO-Q PDUs; see clause 21. MS support of extended advanced link(s) is indicated 
in the "class of MS" element in the U-LOCATION UPDATE DEMAND PDU; see clause 16. 

b) When the LLC sends an AL-SETUP PDU for the original acknowledged advanced link, it shall use the lowest 
free (i.e. unused) advanced link number for that address. 

NOTE 2: Therefore, if no extended acknowledged advanced links exist for that address, advanced link number 1 is 
used for the original acknowledged advanced link; in particular, if either LLC does not support extended 
advanced link(s) then advanced link number 1 is always used for the original acknowledged advanced 
link. If both LLCs support extended advanced link(s) and advanced link number 1 is in use for an 
extended acknowledged advanced link then the next free advanced link number is used. 

22.3.3.1 .1 Actions on TL-CONNECT request primitive (set-up phase sending entity) 

Upon reception of a TL-CONNECT request primitive (handle to the request) in any state, the LLC shall: 

i) if the corresponding advanced link is already set up, then the LLC shall cease both sending and reception 

actions, if needed cancel the relevant MAC layer SDU by a TMA-CANCEL request primitive, empty relevant 
data buffers and prepare an AL-SETUP PDU with a report "reset"; or 

if the corresponding advanced link is not already set up, then the LLC shall prepare an AL-SETUP PDU with a 
report "service definition"; 

ii) set the re-try counter to allow the maximum number of connection set-up retries N.262; 

iii) inform the formatter using the DATA_IN_BUFFER signal and enter "WAIT_OUT_CONNECT" state. 

NOTE: The LLC selects parameters for an AL-SETUP PDU according to the TL-CONNECT request primitive 
parameters and current LLC capabilities e.g. available buffer sizes; see clause 20 for parameter 
definitions and clause 21 for PDU definitions. Suitable parameters for a AL-SETUP PDU depend on the 
quality negotiation between the service user and the DLL. The negotiation method is implementation 
dependent. 
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In the "WAIT_OUT_CONNECT" state the LLC may receive: 
Local indication: 

a) a MAC-READY signal and then the LLC shall deliver the waiting AL-SETUP PDU, if any, to the formatter; 

b) a TMA-REPORT indication primitive confirming the handle to the request; 

c) a TMA-REPORT indication primitive (complete transmission) and if reason is "successful complete 
transmission by random access" or "complete transmission by reserved access or stealing", then the LLC shall 
start set-up waiting timer T.261; 

d) a TMA-REPORT indication primitive (random access failure) and then the LLC shall inform a set-up failure 
to the service user by TL-REPORT indication primitive (set-up failure) and return into the "IDLE" state for 
this advanced hnk; 

e) set-up waiting time-out T.261 indication and: 

if more retries (N.262) are available, then the LLC shall issue the previous AL-SETUP PDU into the 
transmission buffer and inform formatter by the DATA_IN_BUFFER signal; 

if all retries (N.262) are used, then the LLC shall inform a set-up failure to the service user by 
TL-REPORT indication primitive (set-up failure) and return into the "IDLE" state for this advanced link; 

PDUs from peer entity: 

f) an AL-SETUP PDU with the report "success" and then the LLC shall issue a TL-CONNECT confirm 
primitive to the service user, stop set-up waiting timer T.261, and prepare the advanced link for data transfer in 
state "CONNECTED"; 

g) an AL-SETUP PDU with report "service change" and then the LLC shall inform the service user by a 
TL-CONNECT indication primitive. The service user shall respond with a TL-CONNECT response primitive 
and the LLC shall act accordingly depending the value of "Set-up report" parameter (see clause 20.2.4.63) 
contained in the TL-CONNECT response primitive: 

if the set-up report indicates that the parameters are acceptable, then the LLC shall prepare an 
AL-SETUP PDU with report "success" and inform formatter using DATA_IN_BUFFER signal. The 
LLC shall continue in the "WAIT_IN_CONNECT" state as defined in clause 22.3.3.1.2 e) to h); 

if the set-up report indicates that the parameters are not acceptable, but there is a possibly suitable 
parameter set available, then the LLC shall prepare an AL-SETUP PDU with report "service change" and 
inform formatter using DATA_IN_BUFFER signal; 

if the parameters are not acceptable and there is no suitable parameter set available, the connection 
establishment is rejected and then the LLC shall prepare an AL-DISC PDU with report "service not 
supported" and inform formatter using DATA_IN_BUFFER signal and deliver the AL-DISC PDU to the 
formatter as the response to the MAC-READY signal and then inform the service user by a 
TL-DISCONNECT indication primitive "set-up failure" and return to the "IDLE" state for this advanced 
link. 

h) an AL-SETUP PDU with report "service definition" and then the LLC shall continue as described in 
clause 22.3.3.1.2 for the "IDLE" state; 

i) an AL-DISC PDU with report "service not supported", "service temporarily unavailable" or "reject" and then 
the LLC shall inform the service user by the corresponding TL-DISCONNECT indication primitive and return 
to the "IDLE" state for this advanced link. 

The MS may receive in the TMA-UNITDATA indication primitive carrying an AL-SETUP PDU the "Channel change 
response required" parameter set to "true"; then the MS shall pass it in the corresponding TL-CONNECT primitive with 
the "Channel change handle" parameter to MLE. 
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22.3.3.1 .2 Actions on AL-SETUP PDU reception (set-up phase receiving entity) 

If the LLC is capable of supporting advanced link, then upon reception of an AL-SETUP PDU for an acknowledged 
advanced link with one of the reports "service definition", "service change" or "reset" when in the "IDLE" state for that 
advanced link number (and address), the LLC shall inform the service user by a TL-CONNECT indication primitive 
with corresponding report and start to wait in state "WAIT_IN_CONNECT". 

If the LLC does not for the moment support advanced link, then upon reception of an AL-SETUP PDU the LLC shall 
prepare an AL-DISC PDU with a report "service temporarily not available", inform formatter by DATA_IN_BUFFER 
signal and issue the AL-DISC PDU as a response to the next MAC-READY signal. 

If the LLC does not at all support advanced link, then upon reception of an AL-SETUP PDU the LLC may prepare an 
AL-DISC PDU with a report "service not supported", inform formatter by DATA_IN_BUFFER signal and issue the 
AL-DISC PDU as a response to the next MAC-READY signal. 

While waiting in state "WAIT_IN_CONNECT" the LLC may receive: 

Service user initiated service primitives: 

a) a TL-CONNECT response primitive with the same parameters as in the TL-CONNECT indication primitive 
and then the LLC shall prepare an AL-SETUP PDU with same parameters as in the received AL-SETUP PDU 
with a report "success" and inform the formatter by a DATA_IN_BUFFER signal; 

b) a TL-CONNECT response primitive with different parameters (less QoS) as in the TL-CONNECT indication 
primitive and then the LLC shall prepare an AL-SETUP PDU with suitable parameters (QoS) and with a 
report "service change", inform the formatter by DATA_IN_BUFFER signal and continue in the 
"WAIT_OUT_CONNECT" state as defined in clause 22.3. 3.L1; 

c) a TL-CONNECT request primitive and then the LLC shall continue as if it had received that primitive from 
the service user as a sending entity, see clause 22. 3. 3. LI; 

d) a TL-DISCONNECT request primitive and then the LLC shall prepare an AL-DISC PDU with a report 
"reject", inform formatter by DATA_IN_BUFFER signal and issue the AL-DISC PDU to the formatter as a 
response to the next MAC -READY signal and then return to the "IDLE" state for this advanced link. 

Local indications due to the AL-SETUP PDU with the report "success" sending: 

e) a MAC-READY signal and then the LLC shall deliver the waiting AL-SETUP PDU to the formatter; 

f) a TMA-REPORT indication primitive confirming the handle to the request; 

g) a TMA-REPORT indication primitive (successful complete transmission by random access or complete 
transmission by reserved access or stealing) and then the LLC shall prepare the advanced link for data transfer 
in state "CONNECTED"; 

h) a TMA-REPORT indication primitive (random access failure) and then the LLC may inform the service user 
by a TL-DISCONNECT indication primitive (set-up failure) and the LLC shall return into the "IDLE" state for 
this advanced link. 

NOTE 1: The LLC entity should not normally receive an AL-SETUP PDU with a report "service change" or "reset" 
when in the "IDLE" state for that advanced link, but if this happens, then the LLC should start normal 
connection establishment as if the received report were "service definition". 

NOTE 2: The LLC entity should not normally receive an AL-SETUP PDU with a report "success" in state "IDLE" 
for that advanced link or in state " WAIT_IN_CONNECT" but, if this happens, then: 

if in state WAIT-IN-CONNECT, the LLC should cancel any AL-SETUP PDU with the report 
"success" sending; and 

■ in either case, the LLC should start normal connection establishment sending an AL-SETUP PDU 
with a report "service definition" as defined in clause 22.3.3.LL 

NOTE 3: A TL-CONNECT response primitive from the service user with a different set of parameters than in the 
corresponding TL-CONNECT indication primitive is taken as a new connect request and the LLC will 
respond to it with a TL-CONNECT confirm primitive before the data transfer may start. 
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The MS may receive in the TMA-UNITDATA indication primitive carrying an AL-SETUP PDU the "Channel change 
response required" parameter set to "true"; then the LLC shall pass it in the corresponding TL-CONNECT primitive 
with the "Channel change handle" parameter to MLE. 

22.3.3.1 .3 Actions on AL-SETUP PDU reception (data transfer state) 

Upon reception of an AL-SETUP PDU for an acknowledged advanced link with a report "reset", "service definition" or 
"service change" when in the "CONNECTED" state for that advanced link number (and address) then: 

i) the LLC shall cease both sending and reception actions for that advanced link, empty relevant data buffers and, 
if needed, cancel any MAC layer sending by TMA-CANCEL request primitive; and 

ii) the LLC shall inform the service user of the reset by a TL-CONNECT indication primitive with the report 
"reset" and start to wait connection set-up progress in state "WAIT_IN_CONNECT" as defined in 
clause 22.3.3.1.2. 

22.3.3.1 .4 Actions on original AL-SETUP PDU reception on different link number 
(data transfer state) 

Upon reception of an AL-SETUP PDU for an original acknowledged advanced link with a report "service definition", 
"service change" or "reset" when in the "CONNECTED" state for an original acknowledged advanced link for that 
address but with a different advanced link number then: 

i) the LLC shall cease both sending and reception actions for the existing original advanced link, empty relevant 
data buffers and, if needed, cancel any MAC layer sending by TMA-CANCEL request primitive; and 

ii) the LLC shall inform the service user of the implicit disconnection of the existing original advanced link and 
go into the "IDLE" state for that advanced link; and 

iii) the LLC shall inform the service user of the incoming set-up by a TL-CONNECT indication primitive and 
start to wait connection set-up progress in state "WAIT_IN_CONNECT" as defined in clause 22.3.3.1.2. 

NOTE: This is an exceptional case which may occur occasionally for an LLC that supports extended advanced 
link(s). It should not occur for an LLC that does not support extended advanced link(s). 

22.3.3.2 Acknowledged data transfer on the original advanced link 

In the advanced link, each data PDU in the acknowledged information transfer is identified by two numbers: a TL-SDU 
sequence number N(S) and a segment sequence number S(S). For the original advanced link, the TL-SDU sequence 
number is a three-bit number incremented in a modulo manner with each transmitted TL-SDU. After the connection 
set-up or after a reset, the sending LLC entity shall start the TL-SDU numbering from "0". The segment sequence 
number is an absolute eight-bit number indicating segments inside a TL-SDU. Those numbers are used in the 
segmentation and re-assembly processes and in the selective re-transmission process. The acknowledgement contains 
the corresponding TL-SDU sequence number N(R) and, in the selective acknowledgement PDU, a segment sequence 
number S(R). The acknowledgement cannot carry any layer 3 information. 

For the original advanced link, the advanced link number is not included in the data transfer and acknowledgement 
PDUs. The advanced link number in the data transfer and acknowledgement PDUs shall be implicitly assumed to be as 
indicated in the AL-SETUP PDU for the original acknowledged advanced link. 

The advanced link can be used for two-way information transfer. 

NOTE: If the BS establishes or accepts an advanced link for the acknowledged service to carry TL-SDUs with a 
maximum length of 4 096 octets then, in the case of a 25 kHz QAM channel, the BS needs to assign an 
event label for that MS address for use on that channel; see clause 23.4. L2. 3. L This is needed in order to 
enable absolute segment numbering with the eight-bit segment sequence number. 
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22.3.3.2.1 Segmentation and sequencing 

The sending advanced link LLC entity shall segment a TL-SDU, if the size of it exceeds: 

• when on a 7i/4-DQPSK or D8PSK channel: the available MAC SDU size; or 

• when on a 25 kHz or 50 kHz QAM channel: the available MAC SDU size in a 4-QAM rate = Vi full-slot MAC 
block at the current bandwidth; or 

• when on a 100 kHz or 150 kHz QAM channel: the available MAC SDU size in half of a 4-QAM rate = V2 
full-slot MAC block at the current bandwidth. 

The MAC sub-layer indicates the next available segment size in the MAC-READY signal and the LLC should use the 
whole available size with possible exception of the last segment. 

Segments shall be sent in sequence. In order to allow a re-assembly in the selective re-transmission, the segments are 
numbered using a S(S) starting from "0" for each TL-SDU. The segment numbering is absolute, therefore a TL-SDU 
shall not comprise more than 256 segments. 

The re- transmission of a segment shall not change the size of that segment, refer to clause 22.3.3.2.3. 

For the original advanced link, the LLC shall use either AL-DATA or AL-DATA-AR PDU for a segment sending if the 
segment is not the last segment of a TL-SDU, and the LLC shall use either AL-FINAL or AL-FIN AL-AR PDU if the 
segment is the last segment of a TL-SDU. The LLC shall use either AL-FINAL or AL-DATA PDUs if no 
acknowledgement is needed at this moment from the peer entity, and either AL-FINAL- AR or AL-DATA-AR PDU 
if acknowledgement is needed at this moment from the peer entity, refer to clause 22.3.3.2.3. 

NOTE: The TL-SDU, as used in this definition, contains the FCS. 

22.3.3.2.2 Re-assembly 

Re-assembly is an operation opposite to segmentation. The receiving LLC entity shall re-assemble the TL-SDU from 
the received segments. The acknowledged advanced link protocol shall deliver received TL-SDUs to the service user in 
the TL-SDU sequence number order. 

At the reception of the first received segment (or every received segment) of a new SDU, the BS LLC entity sends a 
TL-RECEIVE indication primitive to the service user indicating that data input is in progress. 

22.3.3.2.3 Acknowledgement and segment re-transmission mechanisms 

In this LLC protocol the sending entity is responsible for requesting acknowledgements from the receiving entity. The 
sending LLC may request an acknowledgement from the peer LLC and potentially cease data transmission by using 
either the AL-DATA-AR or AL-FINAL-AR PDU. The sending LLC shall request an acknowledgement at latest, when 
it cannot continue sending due to the closing of TL-SDU window. The sending LLC should request an 
acknowledgement each time there is no more data for sending or there will be a pause in sending for other reasons. 
When on a 7i/4-DQPSK channel, the LLC should generally minimize acknowledgement requests in good propagation 
situations. When on a D8PSK or QAM channel, the choice of when the sending LLC requests acknowledgements may 
be affected by the link adaptation algorithm used by the transmitting MS or BS. 

In addition to the requested acknowledgements the receiver may choose to send acknowledgements at any time for its 
own purposes e.g. to clean up receiving buffers. When on a D8PSK or QAM channel, the choice of when the receiver 
sends acknowledgements may be affected by link adaptation aspects. 

The receiving entity acknowledges both whole TL-SDUs and selectively segments of TL-SDUs by either AL-ACK or 
AL-RNR PDUs depending on the flow control needs, refer to clause 22.3.3.2.5. The sending entity shall re-transmit 
only the segments marked as bad in the last received AL-ACK or AL-RNR PDU. The re-transmission of segments shall 
start from the oldest segment in the oldest TL-SDU and continue until all segments for which a re-transmission is 
requested are transmitted. If the sending entity receives an acknowledgement for the whole TL-SDU, it informs the 
service user of the correct transfer of the layer 3 data by issuing a TL-DATA confirm primitive. A segment shall keep 
its original sent segment number S(S), which indicates its absolute position inside the corresponding TL-SDU. The 
same sent TL-SDU number N(S) shall be used until all its segments have been successfully transmitted and the whole 
TL-SDU has been acknowledged (see clause 22.3.3.2.6) or TL-SDU transmission is failed or the advanced link is 
disconnected. 
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Upon reception of the acknowledgement request indicated by the AL-DATA-AR or AL-FINAL-AR PDU, the receiver 
entity shall send either the AL-ACK or the AL-RNR PDU, refer to clause 22.3.3.2.5 for flow control, with one or more 
acknowledgement blocks: 

i) the N(R) element shall indicate which TL-SDU is acknowledged; 

ii) if the acknowledgement is for a whole TL-SDU, then the LLC shall set the acknowledgement length element 
to: 

value OOOOOO2 if the receiver accepts the TL-SDU; 

value llllll2if the receiver requests a re-sending of the TL-SDU; and 

there shall be no other elements in that acknowledgement block. 

iii) if the receiver selectively acknowledges segments of the SDU then: 

the acknowledgement length element shall indicate the number of acknowledged segments; and 

the S(R) element shall indicate the absolute position of the oldest not yet received segment in the 
TL-SDU; and 

the bit map shall indicate the status of each segment starting from the next segment after the S(R) and 
moving forwards one segment at a time, up to the limit imposed by the last correctly received segment or 
by the available room in the AL-ACK or AL-RNR PDU; the status of the segment (STATUS) shall be 
set to " 1 " if it is correctly received and to "0" if it is not correctly received. 

The receiving entity shall include an acknowledgement block for the TL-SDU corresponding to the AL-DATA-AR or 
AL-FINAL-AR. It should also include an acknowledgement block for any older TL-SDUs that are not yet completely 
received or that have not yet been acknowledged as completely received. It may include an acknowledgement block for 
newer TL-SDUs. If the acknowledgement blocks do not fit within one MAC block, then it may send multiple AL-ACK 
(or AL-RNR) PDUs. 

If the data sending entity does not receive an acknowledgement message either AL-ACK or AL-RNR PDU within 
acknowledgement waiting time T.252, then: 

• if the window size for TL-SDU N.272 is fully used, then the sending LLC shall repeat its acknowledgement 
request as above by using the oldest AL-DATA-AR or AL-FINAL-AR PDU as appropriate, for which there is 
no received acknowledgement; or 

• if the SDU window size for TL-SDU N.272 is not fully used, then the sending LLC may continue its 
transmission by using AL-DATA(-AR) or AL-FINAL(-AR) PDU as appropriate. 

NOTE: The sending entity may continue data transmission within the TL-SDU window independently of the 
acknowledgement waiting timer. 

22.3.3.2.4 TL-SDU re-transmission 

In the case that all the segments of a TL-SDU have been received, but the FCS verification has failed, the whole 
TL-SDU shall be re-transmitted if within the allowed number of TL-SDU retransmissions N.273. The receiver shall 
indicate the FCS failure by setting value llllll2to the acknowledgement length information element in the AL-ACK 
or AL-RNR PDU. On the transmitter side, this TL-SDU shall be re-transmitted using the same TL-SDU discriminator 
and starting transmission from the first segment. 

Refer to clause 22.3.3.2.6 for reasons of the sending entity to re-transmit a TL-SDU. 

If the maximum number of TL-SDU re-transmissions N.273 is exceeded, the sending LLC shall abandon the 
transmission of that TL-SDU and report an error to the service user using a TL-REPORT indication primitive "failed 
transfer". The service user should stop using the advanced link and either reset or disconnect it, refer to 
clauses 22.3.3.1.1 and 22.3.3.3 for protocol actions. 
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22.3.3.2.5 Flow control 



During the transmission in an advanced link, the receiving entity has the possibility to interrupt the transmitting entity 
from sending new TL-SDUs. The receiving entity shall use as acknowledgements either an AL-ACK or an AL-RNR 
PDU, if the receiver may continue to receive more data or is not capable of receiving more data respectively. The 
AL-RNR PDU shall also acknowledge already received PDUs and/or segments of PDUs. 

When an AL-ACK or AL-RNR PDU is sent over the air interface, it shall reflect the actual situation at the receiver at 
the transmission time of this acknowledgement. 

Upon reception of an AL-RNR PDU the transmitting entity shall wait until either the peer entity sends an AL-ACK 
PDU or the receiver not ready validity timer for the sending entity T.271 expires (or until the link is disconnected or 
reset). The sender may continue sending of those TL-SDUs, which are partially acknowledged in the AL-RNR PDU or 
previously. The receiving entity may need to send more than one AL-RNR PDU when there are more segments or 
PDUs waiting for positive or negative acknowledgement than fit into one AL-RNR PDU. 

If the receiver not ready validity timer for sending entity T.271 expires, the sending entity shall try to start the sending 
of the TL-SDUs from the first unacknowledged PDU if there is still room in the TL-SDU sending window N.272, or 
from the last segment of the last already acknowledged TL-SDU, if there is no room in the TL-SDU window. If the 
receiving LLC cannot accept the new TL-SDU, it shall acknowledge the last already received and acknowledged 
TL-SDU by an AL-RNR PDU. 

The receiving entity starts the receiver not ready validity timer T.272 when it sends an AL-RNR PDU over the air 
interface. If T.272 expires and the receiving entity is still incapable of receiving data, it may restart T.272 and send 
another AL-RNR PDU. T.272 is reset when the receiving entity sends an AL-ACK PDU over the air interface which 
indicates that the receiver is again capable of receiving data. 

22.3.3.2.6 Actions on TL-DATA request primitive (sending entity) 

During acknowledged data transfer the LLC sending entity may receive (in state " AL_TX_READY") from the service 
user: 

a) a TL-DATA request primitive (handle to the request) and then: 

i) the sending LLC may issue a TL-REPORT indication primitive confirming the handle to the request 
parameter; 

ii) the LLC shall calculate the PCS and append it to the TL-SDU; 

iii) the LLC shall save the TL-SDU with the PCS into sending buffer and inform the MAC layer how much 
data is available for sending by the D AT A_IN_B UPPER signal, see clause 22.3.1.7.2; 

local indications: 

b) MAC -READY signal and then: 

if there are no segments pending for re-transmission, the LLC shall format a new segment of the 
TL-SDU in the sending buffer as defined in clause 22.3.3.2.1 and issue it to the formatter and set the 
corresponding segment re-transmission counter; 

if there is at least one segment pending for re-transmission and the maximum number of segment 
retransmissions N.274 of that segment is not exceeded, then the LLC shall select the oldest segment, for 
which there is a re-transmission request pending and issue the PDU to the formatter; 

if there is at least one segment pending for re-transmission and the maximum number of the segment 
retransmissions N.274 of that segment is exceeded but the maximum number of TL-SDU retransmissions 
N.273 is not exceeded, then the LLC shall start re-sending of the complete TL-SDU (using the original 
segmentation) and issue it to the formatter; 

if there is at least one segment pending for re-transmission and both the maximum number of segment 
retransmissions N.274 of that segment and the maximum number of TL-SDU retransmissions N.273 are 
exceeded, then the LLC shall inform the service user about TL-SDU transmission failure by a 
TL-REPORT indication primitive (failed transfer); 
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c) an indication, that the acknowledgement waiting timer T.252 has expired, refer to acknowledgement 
mechanisms in clause 22.3.3.2.3 for actions; 

d) a TMA-REPORT indication primitive confirming the handle to the request; 

e) a TMA-REPORT indication primitive (successful complete transmission by random access or complete 
transmission by reserved access or stealing) and, if it is a response to either a AL-D ATA-AR or 
AL-FINAL-AR PDU, the LLC shall start acknowledgement waiting timer T.252; 

f) a TMA-REPORT indication primitive (random access failure) and then: 

i) if the random access attempt was on a conforming 7i/4-DQPSK or D8PSK channel, the LLC shall inform 
the service user by a TL-REPORT indication primitive (failed transfer) and the LLC shall delete the 
TL-SDU from the sending buffer; 

ii) if the random access attempt was on a non-conforming n/4-DQPSK or D8PSK channel, or a QAM 

channel, the LLC may inform the service user by a TL-REPORT indication primitive (failed transfer) in 
which case the LLC shall delete the TL-SDU from the sending buffer; 

NOTE 1 : After receiving a TL-REPORT indication primitive reporting failed transfer (see b) and f) above) the 
service user should immediately either reset or disconnect the advanced link, which should be no more 
usable in the current state. 

NOTE 2: In case f)ii), if the LLC does not inform the service user by a TL-REPORT indication primitive (failed 

transfer), the LLC may continue to attempt to send the TL-SDU (using the current segmentation) and the 
service user need not reset or disconnect the advanced link. However the MS should not keep attempting 
random access excessively on the same channel after a random access failure. 

PDUs from peer entity: 

g) an AL-ACK PDU either to acknowledge received segments and/or TL-SDUs or to indicate that the peer entity 
is capable to receive more data; refer to clause 22.3.3.2.3 for the actions on the acknowledgement; 

h) an AL-RNR PDU to acknowledge received TL-SDUs and/or segments and to indicate that the peer entity is 
currently not capable to receive more data; refer to flow control in clause 22.3.3.2.5. 

NOTE 3: In this clause word segment is used instead of AL-D ATA, AL-D ATA-AR, AL-FINAL and 
AL-FINAL-AR PDUs, refer to segmentation in clause 22.3.3.2.1 and acknowledgement in 
clause 22.3.3.2.3 for selection of the correct PDU. 

NOTE 4: The TL-SDU sending window is updated when the lowest SDU in the current window is completely 
acknowledged. 

The MS may receive in the TMA-UNITDATA indication primitive carrying an AL-ACK or AL-RNR PDU the 
"Channel change response required" parameter set to "true"; then the MS shall pass it in a TL-REPORT indication 
primitive with the "Channel change handle" parameter to MLE. 

22.3.3.2.7 Data reception from the peer entity (receiving entity) 

When advanced link LLC receiving entity is ready for receiving data (in the state "AL_RX_READY"), it may receive: 
Local indications: 

a) MAC -READY signal and then the LLC shall send the AL-ACK or AL-RNR PDU as appropriate, see later in 
this clause and in clause 22.3.3.2.3 for the acknowledgement procedure; 

PDUs from the peer entity: 

b) AL-D ATA or AL-FINAL PDU and then the LLC shall store the segment into the correct position for 
reassembling in the corresponding TL-SDU and shall check completeness and correctness of the received 
TL-SDU; and 

if the TL-SDU is completely and correctly received (FCS matches) the LLC shall mark it received and 
ready for acknowledgement; and 
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if the number of the TL-SDU (N(S)) is the lowest SDU in the receiver window the LLC shall update 
both the lower and upper window boundary and deliver the received TL-SDU to the service user in a 
TL-DATA indication primitive; or 

NOTE 1 : If the next TL-SDU (or TL-SDUs) in the sequence have already been completely and correctly received, 
the LLC also delivers that TL-SDU (or those TL-SDUs) to the service user. 

if all segments of that TL-SDU are received, but the PCS calculation fails, then the LLC shall discard 
that SDU and mark that it needs to be re-transmitted. 

c) AL-DATA-AR or AL-FINAL-AR PDU and then the LLC shall store the segment into the correct position for 
reassembling in the corresponding TL-SDU and shall check completeness and correctness of the received 
TL-SDU; and 

if at least one new TL-SDU is completely and correctly received (PCS matches) the LLC shall mark it 
received and prepare either AL-ACK or AL-RNR PDU as defined in clause 22.3.3.2.5 with a possible 
bitmap of the unacknowledged segments in the other SDUs, inform the formatter by the 
D AT A_IN_B UPPER signal and, if the number of the TL-SDU (N(S)) is the lowest SDU in the receiver 
window, the LLC shall update the lower window boundary and deliver the received TL-SDU to the 
service user in a TL-DATA indication primitive; 

NOTE 2: If the next TL-SDU (or TL-SDUs) in the sequence have already been completely and correctly received, 
the LLC also delivers that TL-SDU (or those TL-SDUs) to the service user. 

NOTE 3: In case the BS LLC entity receives an AL-DATA(-AR) or AL-PINAL(-AR) PDU with a new TL-SDU 
number N(S), the BS LLC should indicate to the LLC service user that the reception of new TL-SDU has 
started by a TL-RECEIVE indication primitive. 

if all segments of that TL-SDU are received, but the PCS calculation fails, then the LLC shall discard 
that PDU and prepare either AL-ACK or AL-RNR PDU asking for re-transmission of that TL-SDU, with 
a possible bitmap of the unacknowledged segments in the other SDUs and inform the formatter by the 
DATA_IN_BUPPER signal; 

if no TL-SDU is received correctly, then the LLC shall mark the segment received and prepare either 
AL-ACK or AL-RNR PDU, with a bitmap of the unacknowledged segments in this and possibly other 
SDUs and inform the formatter by the D AT A_IN_B UPPER signal; 

The LLC shall use PDU priority level = 5 and allow frame stealing for a response to an AL-DATA-AR or 
AL-PINAL-AR PDU (though in most cases neither of these parameters will actually be used in the MAC, 
since AL-ACK and AL-RNR PDUs are usually sent by reserved access). 

indication from the service user: 

d) a PLOW-NOT-READ Y signal and then the LLC shall prepare an AL-RNR PDU, with a possible bitmap of the 
unacknowledged segments in the received SDUs and inform the formatter by the DATA_IN_BUPPER signal; 

e) a PLOW -READY signal and then the LLC shall prepare an AL-ACK PDU, with a possible bitmap of the 
unacknowledged segments in the received SDUs and inform the formatter by the DATA_IN_BUPPER signal, 
refer to flow control in clause 22.3.3.2.5. 

NOTE 4: The receiving process delivers TL-SDUs in the sequence defined by the N(S). 

NOTE 5: If it receives any of the data transfer PDUs (AL-DATA, AL-DATA-AR, AL-PINAL or AL-PINAL-AR), 
when the corresponding advanced link is no more in "RX_READY" state, then the PDU will be discarded 
in this model by the formatter without any further actions. 

NOTE 6: When the LLC receiving entity has completely and correctly received a TL-SDU, and if the number of 
the TL-SDU is the lowest in the receiver window, then the LLC updates the lower window boundary and 
delivers the received TL-SDU to the service user. However, even when the LLC has sent an 
acknowledgement for the correctly received TL-SDU, that acknowledgement may not have been received 
by the sending entity. Therefore the LLC may still receive AL-DATA(-AR) and AL-PINAL(-AR) PDUs 
for the N.272 TL-SDUs below the current receiver window. If this occurs, the receiving LLC should 
discard the received segment(s) but should send an acknowledgement to indicate that the TL-SDU has 
been correctly received. 
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NOTE 7: In the LLC advanced link protocol the sending entity should retry transmission in case it does not receive 
an expected acknowledgement since the protocol actions taken in case of a transmission failure of an 
AL-ACK or AL-RNR PDU are not defined in the present document. 

The MS may receive in the TMA-UNITDATA indication primitive carrying an AL-DATA(-AR) and AL-FINAL(-AR) 
PDU the "Channel change response required" parameter set to "true"; then the MS shall pass it in a TL-REPORT 
indication primitive or if available in the corresponding TL-DATA indication primitive with the "Channel change 
handle" parameter to MLE. 

22.3.3.2a Acknowledged data transfer on an extended advanced link 

For acknowledged data transfer on an extended advanced link, the procedures described in clause 22.3.3.2 shall apply 
for that extended advanced link with the following differences: 

i) PDUs AL-X-DATA, AL-X-DATA-AR, AL-X-FINAL, AL-X-FINAL-AR, AL-X-ACK and AL-X-RNR shall 
be used instead of PDUs AL-DATA, AL-DATA-AR, AL-FINAL, AL-FINAL-AR, AL-ACK and AL-RNR 
respectively. 

ii) The advanced link number shall be included in each PDU. 

iii) The TL-SDU sequence number shall be a five-bit number incremented in a modulo manner with each 
transmitted TL-SDU (instead of a three-bit number). 

iv) The window size N.272 may be larger for an extended advanced link than for the original advanced link. 

NOTE: As in clause 22.3.3.2.3: when acknowledging TL-SDUs, if the acknowledgement blocks do not fit within 
one MAC block, the receiving entity may send multiple AL-X-ACK (or AL-X-RNR) PDUs. 

v) Use of the PCS is optional on an extended advanced link, so: 

the sending entity only calculates the ECS and appends it to the TL-SDU (see clause 22.3.3.2.6) if 
requested by the service user in the TL-DATA request primitive; 

if the AL-X-FINAL or AL-X-FINAL-AR PDU indicates that the ECS is not present then, when the 
receiving entity is re-assembling the TL-SDU (see clause 22.3.3.2.7), it shall check only for 
completeness of the TL-SDU instead of checking for completeness and correctness. 

vi) The LLC header of the AL-X-FINAL and AL-X-FINAL-AR PDU is one bit longer than the LLC header of the 
AL-X-DATA and AL-X-DATA-AR PDU. Therefore there are occasional cases when the last part of the 
TL-SDU (and ECS when used) just fits within an AL-X-DATA or AL-X-DATA-AR PDU but would not fit 
within an AL-X-FINAL or AL-X-FINAL-AR PDU. In these cases, the sending LLC entity should send the last 
part of the TL-SDU (and ECS when used) within an AL-X-DATA or AL-X-DATA-AR PDU and then send an 
empty AL-X-FINAL or AL-X-FINAL-AR PDU (i.e. containing no information after the ECS flag) to 
complete the TL-SDU transmission. 

Therefore the receiving LLC entity may occasionally receive an AL-X-FINAL or AL-X-FINAL-AR PDU 
containing no information after the ECS flag. The AL-X-FINAL or AL-X-FINAL-AR PDU indicates the 
termination of the TL-SDU so, when all the other segments have been received, those other segments comprise 
the complete TL-SDU (and ECS when used). 

For the purposes of the acknowledgement protocol, both the sending entity and the receiving entity shall 
process the empty AL-X-FINAL or AL-X-FINAL-AR PDU using the usual procedures for an AL-X-FINAL 
or AL-X-FINAL-AR PDU. For example, when required by the usual procedures, the receiving entity shall 
include a bit in the acknowledgement bit map to indicate successful reception of the AL-X-FINAL or 
AL-X-FINAL-AR PDU. 

vii) On a D8PSK or QAM channel, link adaptation feedback information may be included within AL-X-ACK and 
AL-X-RNR PDUs; see clause 22.3.1.7.3. 

If an MS is using more than one advanced link, the data transfer procedures for each advanced link operate 
independently of the data transfer procedures for the other advanced hnk(s). 
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22.3.3.3 Release of acknowledged service advanced link 

In the advanced link the end of the transfer shall be notified by AL-DISC PDU with reason "close". In the 
acknowledged data transfer the disconnection shall be confirmed by sending a AL-DISC PDU with reason "success". 
Disconnection may occur at any time. When the receiving entity recognizes a disconnect it shall delete all partially 
received TL-SDUs for that advanced link. 

22.3.3.3.1 Actions on TL-DISCONNECT request primitive (MS sending entity) 

Upon reception of a TL-DISCONNECT request primitive in state WAIT_OUT_CONNECT or CONNECTED, the LLC 
shall: 

i) prepare an AL-DISC PDU with reason "Close" and inform the formatter by DATA_IN_BUFFER signal; 

ii) set re-try counter to allow the maximum number of connection disconnect retries N.263; 

iii) cease all sending and receiving any data and discard all TL-SDUs waiting for sending on this advanced link or 
which are partially received on this advanced link and start to wait in "WAIT_DISCONNECT" state. 

In the "WAIT_DISCONNECT" state the LLC may receive: 

Local indications: 

a) a MAC-READY signal and then the LLC shall issue the AL-DISC PDU to the formatter; 

b) a TMA-REPORT indication primitive (successful complete transmission by random access or complete 
transmission by reserved access or by stealing) and then the LLC shall start the disconnection waiting 
timer T.263; 

c) a TMA-REPORT indication primitive (random access failure) and then the LLC shall inform the service user 
by a TL-DISCONNECT confirm primitive (random access failure) and go into the "IDLE" state for this 
advanced link; 

d) an indication of the expiry of the disconnection waiting timer T.263 and: 

if more retries (N.263) are available, then the LLC shall issue the previous AL-DISC PDU into the 
transmission buffer and inform formatter by the DATA_IN_BUFFER signal; 

if all retries (N.263) are used, then the LLC shall inform the service user by a TL-DISCONNECT 
confirm primitive (disconnection failure) and go into the "IDLE" state for this advanced link. 

A PDU from the peer entity: 

e) an AL-DISC PDU with reason "Success", then the LLC shall inform the service user by a TL-DISCONNECT 
confirm primitive and go into the "IDLE" state for this advanced link; 

f) an AL-DISC PDU with reason "Close", then the LLC shall deliver an AL-DISC PDU with reason "Success" to 
the formatter as a response to the next MAC-READY signal and go into the "IDLE" state for this advanced 
hnk. 

22.3.3.3.2 Actions on AL-DISC PDU reception (MS receiving entity) 

While being ready for data transfer the advanced link LLC may receive: 

A PDU from the peer entity: 

a) an AL-DISC PDU with reason "Close" and then: 

i) the LLC shall stop sending and receiving any data and discard both TL-SDUs waiting for sending on this 
advanced link and TL-SDUs which are partially received or fully received on this advanced link; 

ii) prepare an AL-DISC PDU with a reason "Success" and inform the formatter by the DATA_IN_BUFFER 
signal; 
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iii) indicate to the service user the removal of the advanced link using a TL-DISCONNECT indication 
primitive "incoming disconnection"; 

Local indications after preparing an AL-DISC PDU: 

b) a MAC-READY signal and then the LLC shall issue the AL-DISC PDU to the formatter; 

c) a TMA-REPORT indication primitive (successful complete transmission by random access or complete 
transmission by reserved access or by stealing) and then the LLC shall go into the "IDLE" state for this 
advanced link; 

d) a TMA-REPORT indication primitive (random access failure) and then the LLC shall go into the "IDLE" state 
for this advanced link. 

When the LLC receives in the "IDLE" state an AL-DISC PDU with reason "Close", the LLC shall deliver an AL-DISC 
PDU with reason "Success" to the formatter as a response to the next MAC-READY signal. 

NOTE: An MS may receive an AL-DISC PDU also in other states of the LLC protocol, refer to advanced link 
establishment actions. 

22.3.3.4 Abnormal release of advanced link 

While in any state the advanced link LLC may receive: 

a) a TL-RELEASE request primitive from the service user and then the LLC shall close the advanced link 
without any signalling with the peer entity and go to the "IDLE" state for this advanced link; 

b) a TMA-RELEASE indication primitive and then the LLC shall close the advanced link(s) corresponding to 
this endpoint identifier without any signalling with the peer entity, indicate link disconnection to the service 
user by TL-DISCONNECT indication primitive(s) with a reason "local disconnection" and go to the "IDLE" 
state for that advanced link (or those advanced links). 

22.3.3.5 Reconnection of acknowledged service advanced link 

A request to reconnect an advanced link shall be notified using the AL-RECONNECT PDU with a reconnect report 
"propose". A successful reconnection of the advanced link shall be confirmed by the reception of an AL-RECONNECT 
PDU with the reconnect report "accept" and unsuccessful reconnection by the reception of an AL-RECONNECT PDU 
with the reconnect report "reject". 

Upon reception of a TL-RECONNECT request primitive when in state "CONNECTED" for that advanced link, the 
LLC shall: 

i) prepare an AL-RECONNECT PDU with reason "propose" and inform the formatter by DATA_IN_BUFFER 
signal; 

ii) set re-try counter to allow the maximum number of reconnect retries N.265; 

iii) cease all sending and receiving any data and start to wait in "WAIT_RECONNECT" state. 
In the "WAIT_RECONNECT" state the LLC may receive: 
Local indications: 

a) a MAC-READY signal and then the LLC shall issue the AL-RECONNECT PDU to the formatter; 

b) a TMA-REPORT indication primitive (successful complete transmission by random access or complete 
transmission by reserved access or by stealing) and then the LLC shall start the reconnection waiting 
timer T.265; 

c) a TMA-REPORT indication primitive (random access failure) and then the LLC shall inform the service user 
by a TL-RECONNECT confirm primitive with the reconnection result set to "random access failure"; 
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d) an indication of the expiry of the reconnection waiting timer T.265 and: 

if more retries (N.265) are available, then the LLC shall issue the previous AL-RECONNECT PDU into 
the transmission buffer and inform formatter by the D AT A_IN_B UPPER signal; 

if all retries (N.265) are used, then the LLC shall inform the service user by a TL-RECONNECT confirm 
primitive with the reconnection result set to "reconnection failure". 

A PDU from the peer entity: 

e) an AL-RECONNECT PDU with reason "accept", then the LLC shall inform the service user by a 
TL-RECONNECT confirm primitive with the reconnection result set to "success" and go into the 
"CONNECTED" state for this advanced link, accept the channel change, if any, by issuing 

a TMC-CONPIGURE request primitive to MAC with the parameter channel change accepted set to "accept" 
and continue to transmit and receive TL-SDU segments without resetting the advanced link; 

f) an AL-RECONNECT PDU with reason "reject", then the LLC shall inform the service user by a 
TL-RECONNECT confirm primitive with the reconnection result set to "reject" and accept the channel 
change, if any, by issuing a TMC-CONPIGURE request primitive to MAC with the parameter channel change 
accepted set to "accept". 

22.3.4 Advanced link procedures for unacknowledged service 

The unacknowledged service uses the same mechanisms for sequencing, segmentation and re-assembling as the 
acknowledged service (see clauses 22.3.3.2.1 and 22.3.3.2.2). The window size for TL-SDU in unacknowledged service 
N.281 defines how many TL-SDUs may be in transit at the same time. The numbering of TL-SDUs N(S), contrary to 
the acknowledged service, may start at any value. 

22.3.4.1 Advanced link unacknowledged service establishment 

The BS should establish the unacknowledged service before it starts to send data. 

The BS should start unacknowledged data transfer by sending one or more AL-SETUP PDUs. During unacknowledged 
data transfer the BS may repeat the AL-SETUP PDU using the current value for the TL-SDU number N(S) to 
re-synchronize receiving MSs. The TL-SDU numbering may start at any value to allow re-setting of an 
unacknowledged service without re-setting the TL-SDU window position. After the reception of an AL-SETUP PDU 
the TL-SDU window lower edge shall be the TL-SDU number N(S) and the upper edge shall be N(S) + N.281 - 1. 
(N.281 is the window size for TL-SDUs in the unacknowledged service.) After sending an AL-SETUP PDU the BS 
should not repeat any TL-SDU or segments of those having a TL-SDU sequence number lower than the one (N(S)) 
indicated in the AL-SETUP PDU. 

NOTE: If the BS establishes an advanced link for the unacknowledged service to carry TL-SDUs with a 

maximum length of 4 096 octets then, in the case of a 25 kHz QAM channel, the BS needs to assign an 
event label for that address for use on that channel; see clause 23.4.1.2.3.1. This is needed in order to 
enable unique segment numbering with the eight-bit segment sequence number. 

22.3.4.2 Reception of unacknowledged service data on the original advanced link 

The LLC MS entity may receive at any state: 

a) an AL-SETUP PDU for unacknowledged information reception and then the LLC shall empty possible current 
buffer for this advanced link, prepare a new buffer for data reception, inform the service user by a 
TL-CONNECT indication primitive (unacknowledged service) and start to wait for data in the state 

" AL_UN ACK_READ Y" ; 

b) an AL-DISC PDU and then the LLC shall discard all partially received TL-SDUs on this advanced link and 
may deliver a TL-DIS CONNECT indication primitive to the service user. 

If the LLC MS entity is in state AL_UNACK_READ Y for an original unacknowledged advanced link and it receives an 
AL-SETUP PDU for an original unacknowledged advanced link for that address but with a different advanced link 
number, the LLC shall empty possible current buffer for the existing original advanced link, prepare a new buffer for 
data reception, inform the service user by a TL-CONNECT indication primitive (unacknowledged service) and wait for 
data in the state "AL_UNACK_READY". 
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NOTE 1: If the LLC MS entity does not support the augmented AL-SETUP PDU and it receives an AL-SETUP 
PDU for the unacknowledged service (i.e. "advanced Unk service" element set to 0) with the "TL-SDU 
window size" element set to OO2, it should discard the AL-SETUP PDU without performing any of the 
actions in the above paragraph or in procedure a). 

While in the "AL_UNACK_READY" state the MS LLC may receive an AL-UDATA PDU or an AL-UFINAL PDU; 
and: 

• if the corresponding TL-SDU is not earlier delivered to the service user, then the LLC shall store the segment 
into correct position of the relevant TL-SDU as indicated by N(S) and S(S) elements respectively; and 

• if a TL-SDU is now completely and correctly received, then the LLC shall deliver the TL-SDU to the service 
user in a TL-UNITDATA indication primitive and mark the TL-SDU as received. 

NOTE 2: The MS LLC may deliver the received TL-SDUs out of sequence. 

NOTE 3: The advanced link protocol allows suppression of received duplicates. 

Each time the LLC receives an AL-UDATA or an AL-UFINAL PDU the LLC shall upgrade the receiving window 
upper edge to the received N(S) if it is higher than the current upper edge and calculate a new lower edge. The LLC 
shall then check if there are any partially received TL-SDUs, which have TL-SDU number outside the new receiving 
window and then the LLC shall discard those partially received SDUs. 

The advanced link number is not included in the AL-UDATA and AL-UFINAL PDUs. The advanced link number in 
the AL-UDATA and AL-UFINAL PDUs shall be implicitly assumed to be as indicated in the AL-SETUP PDU for the 
original unacknowledged advanced link. 

NOTE 4: An AL-SETUP PDU for unacknowledged information reception (or an AL-UDATA or AL-UFINAL 
PDU) may be sent in a group addressed MAC PDU that contains a channel allocation. If the MS-MAC 
requires instruction on whether to accept the channel allocation, then it sets the "channel change response 
required" parameter to "true" in the TMA-UNITDATA indication primitive. If the MS decides to accept 
the channel allocation then the higher layers should issue a TMC-CONFIGURE request primitive to the 
MAC containing the "channel change handle" parameter and "channel change accepted" parameter set to 
"accept". However, if a channel change is not acceptable, a TMC-CONFIGURE request primitive should 
be issued with the "channel change parameter" set to "reject". 

22.3.4.2a Reception of unacknowledged service data on an extended advanced link 

For reception of unacknowledged service data on an extended advanced link, the procedures described in 
clause 22.3.4.2 shall apply for that extended advanced link with the following differences: 

i) PDUs AL-X-UDATA and AL-X-UFINAL shall be used instead of PDUs AL-UDATA and AL-X-UFINAL 
respectively. 

ii) The advanced link number is included in each PDU. 

iii) The window size N.281 may be larger for an extended advanced link than for the original advanced link. 

iv) Use of the FCS is optional on an extended advanced link so, if the AL-X-UFINAL PDU indicates that the FCS 
is not present, the LLC MS entity shall deliver the TL-SDU to the service user when it has received the 
complete TL-SDU (without checking for correctness). 

v) The LLC header of the AL-X-UFINAL PDU is one bit longer than the LLC header of the AL-X-UDATA 
PDU. Therefore there are occasional cases when the last part of the TL-SDU (and FCS when used) just fits 
within an AL-X-UDATA PDU but would not fit within an AL-X-UFINAL PDU. In these cases, the BS LLC 
may send the last part of the TL-SDU (and FCS when used) within an AL-X-UDATA PDU and then send an 
empty AL-X-UFINAL PDU (i.e. containing no information after the FCS flag) to complete the TL-SDU 
transmission. 

Therefore the LLC MS entity may occasionally receive an AL-X-UFINAL PDU containing no information 
after the FCS flag. The AL-X-UFINAL PDU indicates the termination of the TL-SDU so, when all the other 
segments have been received, those other segments comprise the complete TL-SDU (and FCS when used). 
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If an MS is receiving more than one unacknowledged advanced link, the procedures for each advanced link operate 
independently of the procedures for the other advanced link(s). 

22.3.4.3 Sliding SDU window in unacknowledged service 

The BS LLC should send unacknowledged data using a TL-SDU window size of 1 to the maximum N.28L This means 
that the BS LLC may transmit with any repetitions up to N.281 different TL-SDUs at any time. The BS LLC may start 
to send a new TL-SDU if its window is not currently full. If the BS LLC wishes to send a new TL-SDU when its 
window is full then it may either: 

• wait until all repetitions of the oldest TL-SDU in the window are completed and then start to send the new 
TL-SDU; or 

• cease transmission of the oldest TL-SDU in the window (including any repetitions) and start to send the new 
TL-SDU. 

The BS LLC indicates the TL-SDU window size at the establishment of the advanced link by sending one or more 
AL-SETUP PDUs. 

NOTE: The window size N.28 1 may be larger for an extended advanced link than for the original advanced link. 

22.3.4.4 Disconnection of unacknowledged data transfer 

The BS may disconnect an unacknowledged service by sending one or more AL-DISC PDUs. When the MS receives an 
AL-DISC PDU it shall discard all partially received TL-SDUs on this advanced link and cease reception of all 
AL-UD ATA PDUs (in the case of the original advanced link) or AL-X-UDATA PDUs (in the case of an extended 
advanced link). 

22.3.5 Channel change request handling 

The MAC layer may issue with TMA-UNITDATA indication primitive "channel change response required" parameter 
with value "true" indicating that an upper layer shall provide a response to MAC layer. 

Upon reception of a "channel change response required" in a TMA-UNITDATA indication primitive: 

• if the TMA-UNITDATA indication primitive contains a TL-SDU, the LLC shall pass the request to MLE in 
the corresponding TL-UNITDATA indication primitive; 

• if the TMA-UNITDATA indication primitive contains no TL-SDU and the endpoint identifier refers to an 
advanced link service MAC resource, the LLC may pass the request to the MLE in a TL-REPORT indication 
primitive or decide to accept or reject the request based on the other LLC services and their importance; 

NOTE 1 : The same endpoint identifier refers to the advanced link(s) and to the related basic link when advanced 
link(s) exist. 

NOTE 2: The service importance determination at the LLC is outside the scope of the present document. 

• if the TMA-UNITDATA indication primitive contains no TM-SDU and the endpoint identifier refers only to 
the basic link service MAC resource and there is only a single user of LLC services, the LLC shall pass the 
request to the MLE in a TL-REPORT indication primitive; 

NOTE 3: How LLC knows the number of service users is outside the scope of the present document. 

• in other cases the actions are outside the scope of the present document. 

The MAC layer may issue TMC-CONFIGURE indication primitive due to various resource conflicts. Upon reception 
of a TMC-CONFIGURE indication primitive with reason "loss of physical resources", the LLC shall indicate to the 
MLE in a TL-CONFIGURE indication primitive the loss of physical resources for that endpoint identifier. Also: 

• if the TMC-CONFIGURE indication primitive is related to an advanced link and the MS supports advanced 
link continuation and there are one or more uncompleted TL-SDUs in the send or reception buffer, the LLC 
shall retain the advanced link for a potential continuation without sending any new TMA-UNITDATA request 
primitives for that advanced link; 



£75/ 



697 ETSI TS 100 392-2 V3.3.1 (2008-10) 

NOTE 4: Only SNDCP layer can support advanced link continuation by the MS, refer to clause 28, and any upper 
layers may disconnect locally the advanced link by a TL-RELEASE request primitive. However, use of 
the advanced link may continue if the LLC receives data from the BS on the retained advanced link. 

• if the TMC-CONFIGURE indication primitive is related to an advanced link and the MS supports advanced 
link continuation but there are no uncompleted TL-SDUs in the send or reception buffer, the LLC shall either: 

locally disconnect the advanced link; or 

retain the advanced link for a potential continuation without sending any new TMA-UNITDATA request 
primitives for that advanced link; 

• if the TMC-CONFIGURE indication primitive is related to an advanced link (or links) and the MS does not 
support advanced link continuation, the LLC shall locally disconnect the advanced link (or links). 

Upon reception of a TMC-CONFIGURE indication primitive with reason "gain of physical resources" the LLC may 
continue to use the indicated MAC resource. 

NOTE 5: Before LLC can use the resource for a retained advanced link, the continuation of the link is first invoked 
by upper layer actions (refer to clause 28) or the LLC receives data from the BS on the retained advanced 
link. 

The MAC layer may also issue a TMA-RELEASE indication primitive due to loss of radio resources, when the loss is 
detected locally without a signalling from BS. The LLC behaviour is defined in clause 22.3.3.4. 



22.3.6 Activity Inandling 



On reception of a TL-CONFIGURE request primitive and the MLE activity parameter has sleep mode value "stay 
alive" the LLC shall send a TMC-CONFIGURE request primitive with MLE activity indicator parameter set to value 
"stay alive". 

On reception of a TL-CONFIGURE request primitive and the MLE activity parameter has sleep mode value "sleep 
permitted" the LLC shall check whether an advanced link is in advanced link establishment or reset phase, see 
clause 22.3.3. 1, advanced link reconnection phase, see clause 22.3.3.5 or in advanced link disconnection phase, see 
clause 22.3.3.3. If no advanced link is in any of those states, then the LLC shall send a TMC-CONFIGURE request 
primitive with MLE activity indicator parameter set to value "sleep permitted". 

Upon the start of an advanced link establishment or reset phase, see clause 22.3.3.1, advanced link reconnection phase, 
see clause 22.3.3.5 or advanced link disconnection phase, see clause 22.3.3.3, the LLC shall send a TMC-CONFIGURE 
request primitive with MLE activity indicator parameter set to value "stay alive", if LLC has not yet informed MAC to 
stay alive. 

When all ongoing advanced link establishment or reset, advanced link reconnection or advanced link disconnection 
phases have been completed, the LLC shall send a TMC-CONFIGURE request primitive with MLE activity indicator 
parameter set to value "sleep permitted" unless the MLE has asked in a TL-CONFIGURE request primitive to "stay 
ahve". 



22.3.7 Layer 2 signalling procedures 



The layer 2 signalling PDUs carry various types of general signalling information relating to layer 2 functions - either 
LLC or MAC functions. For convenience, the layer 2 signalling PDUs are treated as LLC PDUs in the PDU structures. 

In the present document, the layer 2 signalling PDUs are used only for MAC functions. 

The LLC procedures in an MS for layer 2 signalling are described in the following clauses. 
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22.3.7.1 Layer 2 signalling procedures (sending entity) 

During sending of layer 2 signalling data corresponding to a MAC function, the LLC may receive: 

a) a TLE-UNITDATA request primitive from the MAC and then the LLC shall: 

store the message in PDU priority order into the sending buffer for sending N.293 + 1 times; and 
indicate new data in the sending buffer to the formatter using the DATA_IN_BUFFER signal; 

b) a MAC-READY signal from the formatter and then the LLC shall form the highest priority layer 2 signalling 
PDU and issue it to the formatter; 

NOTE 1: The formatter delivers the PDU to the MAC using a TMA-UNITDATA request primitive. 

c) a TLE-CANCEL request primitive from the MAC and then: 

if the LLC has already transferred the message to the MAC, it shall issue a TMA-CANCEL request 
primitive; on receipt of a TMA-REPORT indication primitive indicating the result of the cancellation, 
the LLC shall note whether the TM-SDU was completely sent; 

the LLC shall inform the MAC whether the layer 2 signalling message was completely sent at least once, 
using a TLE-REPORT indication primitive; and 

the LLC shall delete the message from the sending buffer; 

d) a TMA-REPORT indication primitive confirming the handle to the request; 

e) a TMA-REPORT indication primitive (first complete transmission by random access), and then the LLC shall 
inform the MAC that the message has been completely transmitted once using a TLE-REPORT indication 

primitive; 

f) a TMA-REPORT indication primitive (successful complete transmission by random access), and then the LLC 
shall: 

inform the MAC that the transfer of the layer 2 signalling message was completed by random access, 
using a TLE-REPORT indication primitive; and 

delete the message from the sending buffer; 

g) a TMA-REPORT indication primitive (complete transmission by stealing or by reserved access), and then, if 
that message has now been completely transmitted once, the LLC shall inform the MAC using a 
TLE-REPORT indication primitive; also, if the message has now been completely transmitted N.293 + 1 
times, the LLC shall: 

inform the MAC that the transfer of the layer 2 signalling message was completed, using a 
TLE-REPORT indication primitive; and 

delete the message from the sending buffer; 

h) a TMA-REPORT indication primitive (failure of fragmentation process) and then: 

if N.293 > 0, the LLC shall try to re-send the layer 2 signalling message so that there shall be at 
maximum N.293 + 1 failed transmissions (in addition to the N.293 + 1 complete transmissions); if there 
have not been N.293 + 1 complete transmissions when the maximum number of failed transmissions 
N.293 + 1 has been reached, then the LLC shall: 

■ inform the MAC that the transfer of the layer 2 signalling message failed, using a TLE-REPORT 
indication primitive; and 

■ delete the message from the sending buffer; 
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if N.293 = 0, the LLC shall try to re-send the layer 2 signalling message so that there shall be at 
maximum two failed transmissions (or the message has been completely transmitted); if there has not 
been one complete transmission when the maximum of two failed transmissions has been reached, then 
the LLC shall: 

■ inform the MAC that the transfer of the layer 2 signalling message failed, using a TLE-REPORT 
indication primitive; and 

■ delete the message from the sending buffer; 

i) a TMA-REPORT indication primitive (random access failure) and then the LLC shall: 

inform the MAC that the transfer of the layer 2 signalling message failed, using a TLE-REPORT 
indication primitive; and 

delete the message from the sending buffer. 

NOTE 2: The MAC may indicate the required number of repetitions (i.e. N.293) in the TLE-UNITDATA request 
primitive, in which case that value is applied for transmission of the message. If the MAC does not 
indicate the required number of repetitions, the value of N.293 chosen by the MS designer is used 
(see annex A). 

NOTE 3: The MS may send more than one layer 2 signalling message in one MAC block (using MAC PDU 
association). 

NOTE 4: For N.293 > 0, the MS should not send the same layer 2 signalling message more than once in one MAC 
block. The layer 2 signalling service does not guarantee in-order delivery at the receiving entity. 
Therefore, in order to use the capacity of MAC blocks by PDU association, the MS may interleave 
retransmissions of multiple layer 2 signalling messages. 

NOTE 5: In the DATA_IN_BUFFER signal, the LLC may include all outstanding layer 2 signalling messages as 
outstanding data ready to be sent, so that the MAC can indicate a reservation requirement for that data. 

NOTE 6: When appropriate, the information in an L2-LINK-FEEDBACK-INF0 PDU may be combined into an 
AL-X-ACK or AL-X-RNR PDU; or the information in an L2-LINK-FEEDBACK-INF0 and 
L2-DATA-PRI0RITY PDU may be combined as an L2-LINK-FEEDB ACK-INFO-AND-RESIDUAL- 
DATA-PRIORITY PDU. According to the protocol model, the combining is performed as described in 
clause 23.3. L7. 3. 2. 

22.3.7.2 Layer 2 signalling procedures (receiving entity) 

Upon reception of a layer 2 signalling PDU from the formatter: 

• in the case of an L2-SCHEDULE-SYNC or L2-LINK-FEEDBACK-CONTROL or 

L2-LINK-FEEDBACK-INFO PDU, the LLC shall inform the MAC of the contents of the PDU using a 
TLE-UNITDATA indication primitive. 

NOTE 1: In the present document, the L2-SCHEDULE-SYNC, L2-LINK-FEEDBACK-CONTROL and 

L2-LINK-FEEDBACK-INFO PDUs are the only types of layer 2 signalling PDU that the MS expects to 
receive. 

NOTE 2: The layer 2 signalling protocol does not suppress received duplicates. 

NOTE 3: The formatter receives the PDU from the MAC in a TMA-UNITDATA indication primitive. 

NOTE 4: The MS may also receive link adaptation feedback information within an AL-X-ACK or AL-X-RNR 
PDU. According to the protocol model, the formatter generates an L2-LINK-FEEDBACK-INFO PDU 
containing the link adaptation feedback information, as described in clause 22.3.1.7.3.1. 
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23 MAC protocol 



This clause describes the V+D air interface layer 2 MAC protocol. It defines the operation of the MAC layer in the MS 
and includes some corresponding rules for the operation of the BS. However, the exact rules for how the BS allocates 
resources to MSs are outside the scope of the present document. 

See EN 300 392-1 [6], clause 6 for the general architecture and a description of all layers including the functionality of 
the MAC sub-layer (see clause 19 for the architecture of the DLL). MAC timers and constants are defined in annex B. 

23.1 MAC services 
23.1.1 Functions of MAC 

In the protocol model, internal communication between the LLC and the MAC uses three SAPs TMA-SAP, TMB-SAP 
and TMC-SAP for services provided by the MAC to the LLC, corresponding to signalling, broadcast and layer 
management functions respectively. A fourth SAP, the TMD-SAP, supports traffic in circuit mode; this service is 
offered directly from the MAC to the U-plane application (e.g. the CODEC). 

Internal communication between the LLC and the MAC also uses a further SAP, TLE-SAP, for the layer 2 signalling 
service provided by the LLC to the MAC. 

The MAC itself is divided into two sub-layers, i.e. the upper and lower MAC. 

The lower MAC performs the channel coding, interleaving and scrambling, as described in clause 8. The upper MAC 
performs the other MAC protocol functions and is described within clause 23. Unless specified otherwise, references to 
"the MAC" throughout clause 23 mean the upper MAC. 

The principal functions of the upper MAC are as follows: 

frame and multiframe synchronization; 

multiplexing/de-multiplexing of the logical channels; 

radio path establishment and channel allocation (for common control channels and for assigned channels); 

address management for the layer 2 address (the source address for the uplink, the destination address for the 
downlink); 

fragmentation of long messages received from the LLC (subdividing the LLC message between more than one 
MAC block); 

association of short messages received from the LLC (enabling more than one message to be sent within one 
MAC block); 

management of power control; 

the random access procedure (contention control); 

granting and use of reserved slots i.e. non-contentious slots reserved by the BS for one MS to send signalling 

message(s); 

path loss calculation: surveillance of the serving cell, monitoring and scanning of adjacent cells, monitoring of 
sectored channels and assessment of channel classes; 

energy economy and napping operation; 

short-term data priority procedure; 

hnk adaptation on D8PSK and QAM channels; 
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providing service to circuit mode applications (e.g. speech CODEC or circuit mode data) on 3i/4-DQPSK 
channels; 

stealing from the traffic channel capacity, when required, to send signalling messages on 7i/4-DQPSK 
channels. 



23.1.2 Service primitives 



The MAC protocol is described in terms of primitives and valid sequences of actions resulting from those primitives. 
Refer to clause 20 for a detailed description of the service primitives. 

The use of primitives throughout clause 23 refers to the protocol definition, but does not imply any specific 
implementation. The MAC boundary, as for other internal boundaries, is defined to clarify the protocol description. The 
word "shall" is used to describe the SAPs and primitives for traceability reasons in the protocol model, but those SAPs 
and primitives are not testable. 

23.1 .2.1 Services at the TMA-SAP 

The TMA-SAP shall be used for the transmission of signalling and packet data information over the air interface. 
Service data units, TM-SDUs, shall be transferred to and from the LLC using the TMA-UNITDATA primitive. (The 
TM-SDU is the LLC PDU, including the LLC header and optional PCS.) 

• The TMA-UNITDATA request primitive from LLC to MAC shall be used when the LLC wishes to send data 
to the peer entity. 

• The TMA-UNITDATA indication primitive from MAC to LLC shall be used to deliver data received from the 
peer entity. 

The MAC in the MS (MS -MAC) shall report the progress of a request procedure locally to the LLC using the 
TMA-REPORT indication primitive. The LLC may abort a TMA-UNITDATA request using the TMA-CANCEL 
request primitive. 

The random access protocol is generally needed when the MS sends a message to initiate a call or transaction. However, 
when an MS is required to send a solicited message or when it has further signalling to send after the initial access, the 
BS may reserve slots for that particular MS. This enables a higher channel throughput to be achieved. Also the MS at 
SNDCP level may negotiate that the BS will grant reserved capacity with a specified repetition period (and specified 
accuracy), in order to support an application which requires regular transmissions of bursts of data; this is called 
scheduled access. When the schedule becomes active, the BS should reserve slots for that MS without the MS needing 
to use random access. 

On a control channel, MSs may transmit only by random access or reserved access. Whereas, during a circuit mode call, 
the transmitting MS may "steal" from the traffic channel capacity to send signalling messages. 

The signalling service offered by the MS -MAC to the LLC shall be an unacknowledged service in the case of 
non-contentious transmission (i.e. reserved access or stealing). The MAC receives a TM-SDU from the LLC, transmits 
the TM-SDU (in one or more MAC blocks) and then reports to the LLC when the message has been sent. 
Acknowledgements and retransmissions are under the control of the LLC. 

However, for contentious access (i.e. random access), the MS-MAC is responsible for sending retries until it receives a 
MAC response from the BS indicating successful random access. The report to the LLC shall then indicate that the BS 
has acknowledged the random access message. 

TMA-SAP signalHng messages may generally be sent using the MAC-RESOURCE or MAC-D-BLCK PDU for the 
downlink, or the MAC-ACCESS PDU (in a subslot) or MAC-DATA or MAC-U-BLCK PDU (in a full slot) for the 
uplink. A general scenario for an exchange of two LLC messages is shown in figure 23. L (Other PDUs, MAC-FRAG 
and MAC-END(-HU), shall be used for continuations and end of a fragmented TM-SDU.) 

The uplink MAC-ACCESS, MAC -DATA and MAC-U-BLCK PDUs shall include the layer 2 address and usually carry 
a TM-SDU; they can also be used to request reserved slots for signalling messages. On the downlink, the 
MAC-RESOURCE PDU usually includes layer 2 addressing and may contain a TM-SDU; the MAC-D-BLCK PDU 
shall include a layer 2 address and may contain a TM-SDU. The MAC-RESOURCE PDU may also include elements 
for granting reserved slots and/or for channel allocation and/or for power control, and the MAC-D-BLCK PDU may 
include an element for granting reserved slots. The MAC PDUs are defined in clause 2L 
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Figure 23.1 : Scenario for exchange of two LLC messages 

23.1.2.1.1 Reports 

When the MS -MAC receives a TMA-UNITDATA request primitive from the LLC, the primitive includes a local 
identifier for the service request, referred to as the "handle to the request". The handle should be retained locally and 
used for routing subsequent reports (TMA-REPORT indication primitive). It refers to all actions required in the MAC 
to accomplish the request. 

The MS-MAC shall issue reports to the LLC at the following times: 

i) first transmission of complete TM-SDU by random access; 

ii) when the BS acknowledges reception of a complete TM-SDU sent by random access; 

iii) complete TM-SDU (or final fragment of a fragmented TM-SDU) has been sent by reserved access or by 
stealing; 

iv) random access failure; 

v) failure of fragmentation process (TM-SDU not completely sent). 

Also, in the case of a TMA-CANCEL request primitive, the MS-MAC shall report whether or not the TM-SDU has 
been completely sent. 

After sending reports ii), iii), iv), v), or after cancellation, the MS-MAC shall regard the requested procedure as 
complete. The MS-MAC shall discard the TM-SDU and the handle becomes invalid. 

23.1 .2.1 .2 Buffering mechanism 

When the MS-MAC receives a downlink PDU addressed to that MS, it shall immediately deliver any TM-SDU to the 
LLC using the TMA-UNITDATA indication primitive (except in the case of a fragmented message, when the 
MS-MAC shall reconstruct the entire TM-SDU before delivering it to the LLC). 

For an MS sending PDUs, there may be many messages to be sent. For the purposes of the protocol description, it is 
assumed that the layer 2 queue of messages is held in the LLC and that the MAC has a sending buffer only. 

According to this protocol description, there shall be two related signals between MS-MAC and MS-LLC. 

i) DATA-IN-BUFFER signal from LLC to MAC. 

This shall indicate: 

the total amount of outstanding signalling data that the LLC has ready to send for a particular address on 
the channel corresponding to the specified endpoint identifier, and not yet given to the MAC; 

if the channel corresponding to the specified endpoint identifier is a 7i/4-DQPSK channel and the MS 
supports data priority: the subdivision of the outstanding data into data priorities; 

if the channel corresponding to the specified endpoint identifier is a D8PSK or QAM channel: the 
subdivision of the outstanding data into data categories; 

if the channel corresponding to the specified endpoint identifier is a D8PSK or QAM channel and the 
MS supports data priority: the subdivision of the outstanding data into data categories and data priorities. 
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It shall also indicate: 



the maximum value of the stealing permission parameter for the messages in the LLC queue for that 
address and channel; 

the maximum value of the PDU priority parameter for unscheduled messages in the LLC queue for that 
address and channel; 

if the MS supports data priority: 

■ the maximum value of the data priority parameter for the messages in the LLC queue for that 
address and channel; and 

■ the type of the next message currently expected to be sent for that address and channel i.e. whether 
the next message will contain packet data or not; 

whether all, some or none of the messages in the LLC queue for that address and channel are fully 
scheduled data, and the lowest value of the maximum schedule interval for any fully scheduled data; 

the maximum value of the PDU priority parameter for fully scheduled messages in the LLC queue for 
that address and channel. 

These parameters enable the MAC to decide on the appropriate means to transfer the information before 
receiving the actual service request. 

ii) MAC-READY signal from MAC to LLC. 

This signal shall be issued to the LLC when the MS-MAC is ready to send a MAC block. 

If the MS is on a 7i/4-DQPSK channel, it shall indicate: 

the maximum size of TM-SDU that can be carried within the MAC PDU that the MS-MAC intends to 
send, i.e. the maximum size without requiring fragmentation. 

If the MS is on a D8PSK channel, it shall indicate: 

the data categories for which a TM-SDU may be sent in the current MAC block; 

the maximum size of TM-SDU that can be carried in the current MAC block for each data category for 
which a TM-SDU may be sent (i.e. the maximum size without requiring fragmentation). 

If the MS is on a QAM channel, it shall indicate: 

the current normal data segment size for advanced link data segments; 

the data categories for which a normal advanced link data segment may be sent in the current MAC 
block; 

the data categories for which a TM-SDU may be sent in the current MAC block; 

the maximum size of TM-SDU that can be carried in the current MAC block for some or all of the data 
categories for which a TM-SDU may be sent (i.e. the maximum size without requiring fragmentation). 

It shall also indicate the absolute maximum size of TM-SDU that can be handled in the MAC at this time. This 
is normally the maximum size of fragmented TM-SDU (up to N.202 bits), but shall be reduced in the case of 
stealing to either the size of the MAC block or to the capacity of two half slots if two-half-slot stealing is 
appropriate at this time. 

On receipt of the MAC-READY signal, the LLC will usually issue a TMA-UNITDATA request primitive to the MAC 
(see also clause 22). 

NOTE: The ISSI and its associated ASSI are equivalent for the purposes of the buffering mechanism, so the MS 
may use the same signal for the ISSI and ASSI. 
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23.1.2.1.3 Usage of signals 



This clause describes the usage of the MAC-READY and DATA-IN -BUFFER signals. The actual MAC procedures for 
fragmentation, association, random access, reserved access and stealing are described later in clause 23. 

The procedures a), b) and c) below relate to the protocol model of the interface with the LLC and do not imply any 
specific implementation. 

a) Random access 

If the DATA-IN-BUFFER signal from the LLC indicates that there is only unscheduled data to send, and if the 
MS -MAC has neither been granted any reserved slots nor asked for reserved slots for that address on that channel, then 
the MS-MAC should prepare to initiate the random access procedure. The MS-MAC shall issue the MAC -READY 
signal to the LLC. On a 7t/4-DQPSK or D8PSK channel, the MAC-READY signal indicates the available size of 
TM-SDU within the MAC-ACCESS PDU. On a QAM channel, the MAC-READY signal indicates that there are no 
data categories for which a normal advanced link data segment may be sent in this MAC block; it may indicate the 
available size of TM-SDU within the MAC- ACCESS PDU. 

i) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that fits within the MAC block 
then the MAC-ACCESS PDU shall carry that TM-SDU. If there is still space within the MAC block for 
another PDU by association, the MS -MAC may repeat the MAC -READ Y/TMA-UNITD ATA exchange 
process as required until there is not space for another MAC header. 

ii) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that does not fit within the 
MAC-ACCESS PDU then the MAC-ACCESS PDU shall carry a first fragment of the TM-SDU, using the 
fragmentation procedure and including a request for reserved capacity within the MAC-ACCESS PDU. 

iii) If the LLC does not issue a TMA-UNITDATA request primitive then the MAC-ACCESS PDU shall contain a 
request for reserved capacity but shall not carry a TM-SDU. This case may arise if the LLC has only advanced 
link messages to send at this time. 

NOTE 1: The maximum available size of TM-SDU in the MAC-ACCESS PDU is variable, depending on whether 
the MS requests reserved capacity for further signalling. 

NOTE 2: On a 7i/4-DQPSK or D8PSK channel, the random access message is always sent using 7i/4-DQPSK 

modulation (on SCH/HU). On a QAM channel, the random access message is always sent using 4-QAM 
modulation with coding rate = Vi and within a 25 kHz bandwidth (on SCH-Q/RA). 

b1) Reserved access on a n/4-DQPSK channel 

When the MS-MAC has a reserved slot (or subslot) individually granted to it by the BS then, if it is already in the 
process of sending a fragmented TM-SDU, it shall send the next fragment. (In the case of a final fragment, if there is 
still space within the MAC block for another PDU by association, the MS-MAC may issue the MAC-READY signal as 
described below.) Or, if there is no data in the LLC buffer for that address and channel, the MS-MAC may send the 
Null PDU. 

Otherwise, just before the transmission is due, the MS-MAC shall issue the MAC-READY signal to the LLC, 
announcing the maximum available size of TM-SDU in this MAC block (i.e. for a full slot, the maximum size of 
TM-SDU in a MAC-U-BLCK PDU (if supported and the MS has an event label) or otherwise in a MAC-DATA PDU; 
for a subslot, the maximum size of TM-SDU in a MAC-ACCESS PDU). 

i) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that fits within the MAC block 
then: 

for a full slot, a MAC-DATA or MAC-U-BLCK PDU shall carry that TM-SDU; use of MAC-U-BLCK 
is appropriate if the MS has an event label and the TM-SDU occupies all, or most of, the MAC block; 

for a subslot, a MAC-ACCESS PDU shall carry that TM-SDU. 

In the case of a MAC-DATA or MAC- ACCESS PDU, if there is still space within the MAC block for another 
PDU by association, the MS -MAC may repeat the MAC -READ Y/TMA-UNITD ATA exchange process as 
required until there is not space for another MAC header. 
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ii) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that does not fit within the 
MAC block then the MAC -DATA PDU (for a full slot) or MAC-ACCESS PDU (for a subslot) shall carry a 
first fragment of the TM-SDU, using the fragmentation procedure and including a request for reserved 
capacity within the MAC -DATA or MAC-ACCESS PDU. 

iii) If the LLC does not issue a TMA-UNITDATA request primitive but the DATA-IN -BUFFER signal indicates 
that there is data to send then the MAC -DAT A or MAC- ACCESS PDU shall contain a request for reserved 
capacity but shall not carry a TM-SDU. This case should not occur for the first PDU in a reserved full slot. 

NOTE 3: The timing of the MAC-READY signal should be as late as possible, to allow the maximum time if the 
layer 3 in the MS is preparing a response to a BS message. 

b2) Reserved access on a D8PSK channel 

When on a D8PSK channel, the MS-MAC maintains an assessment of the appropriate modulation (i.e. 7t/4-DQPSK or 
7I/8-D8PSK) for reserved access transmission for each of the data categories; see clause 23.4.9. 

When the MS-MAC has a reserved slot (or subslot) individually granted to it by the BS then, if it is already in the 
process of sending a fragmented TM-SDU, it shall send the next fragment. (In the case of a final fragment, if there is 
still space within the MAC block for another PDU by association, the MS-MAC may issue the MAC-READY signal as 
described below.) Or, if there is no data in the LLC buffer for that address and channel, the MS-MAC may send the 
Null PDU. 

Otherwise, just before the transmission is due, the MS-MAC shall issue the MAC-READY signal to the LLC, 
announcing the maximum available size of TM-SDU in this MAC block for each data category. 

NOTE 4: The maximum available size of TM-SDU will take one of two values, depending on whether the 

MS-MAC would send data for each data category using 7i/4-DQPSK or ti/S-DSPSK modulation. So, for 
example, if the MS -MAC currently intends to send the first transmission(s) of any advanced link 
segments for background class data using 71/8-D8PSK modulation, but would send the first 
transmission(s) of advanced link segments for telemetry class data using 3i/4-DQPSK modulation, the 
information in the MAC-READY signal enables the LLC to cut new advanced link segments of the 
appropriate size 

Any TMA-UNITDATA request primitive issued by the LLC indicates the data category for the TM-SDU. 

i) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that fits within the MAC block 
using the modulation appropriate for the indicated data category then: 

for a full slot, a MAC-DATA or MAC-U-BLCK PDU shall carry that TM-SDU; use of MAC-U-BLCK 
is appropriate if the MS has an event label and the TM-SDU occupies all, or most of, the MAC block; 

for a subslot, a MAC-ACCESS PDU shall carry that TM-SDU. 

In the case of a MAC-DATA or MAC- ACCESS PDU, if there is still space within the MAC block for another 
PDU by association, the MS -MAC may repeat the MAC -READ Y/TMA-UNITD ATA exchange process as 
required until there is not space for another MAC header. 

In the second (and subsequent) MAC-READY signal for a MAC block, the MS-MAC shall indicate the data 
categories for which a TM-SDU may be sent and the maximum available size of TM-SDU in this MAC block 
for each data category. 

EXAMPLE 1 : If the first TM-SDU can be sent using 31/8-D8PSK modulation and fits within a D8PSK MAC 
block (with space remaining) but would not fit within a 7i/4-DQPSK MAC block then, in the 
second MAC -READY signal, the MS -MAC should not invite data for data categories that must 
use 71/4-DQPSK modulation. If the first TM-SDU can be sent using 71/8-D8PSK modulation but 
would fit within a 7i/4-DQPSK MAC block (with space remaining) then, in the second 
MAC -READY signal, the MS-MAC may choose to invite data for all data categories. 

If the second (or subsequent) TMA-UNITDATA request primitive indicates a data category for which a 
different modulation is appropriate, it is expected that the MS-MAC would use the lower of the modulation 
levels. 
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ii) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that does not fit within the 

MAC block using the modulation appropriate for the indicated data category then the MAC-DATA PDU (for a 
full slot) or MAC- ACCESS PDU (for a subslot) shall carry a first fragment of the TM-SDU, using the 
fragmentation procedure and including a request for reserved capacity within the MAC -DATA or 
MAC- ACCESS PDU. 

iii) If the LLC does not issue a TMA-UNITDATA request primitive but the DATA-IN -BUFFER signal indicates 
that there is data to send then the MAC -DAT A or MAC- ACCESS PDU shall contain a request for reserved 
capacity but shall not carry a TM-SDU. This case should not occur for the first PDU in a reserved full slot. 

After performing the above process, the MS -MAC should use the appropriate modulation according to the data category 
(or categories) of the PDU(s) but with the following exception: if the appropriate modulation for the PDU(s) to be sent 
in a MAC block is 31/8-D8PSK according to the data category (or categories), but the PDU(s) would actually fit within a 
7I/4-DQPSK MAC block, the MS-MAC shall use 7i/4-DQPSK modulation. 

b3) Reserved access on a QAM channel 

When on a QAM channel, the MS-MAC maintains an assessment of the appropriate modulation level and coding rate 
for reserved access transmission for each of the data categories; see clause 23.4.9. 

When the MS-MAC has a reserved slot (or subslot) individually granted to it by the BS then, if it is already in the 
process of sending a fragmented TM-SDU, it shall send the next fragment. (In the case of a final fragment, if there is 
still space within the MAC block for another PDU by association, the MS-MAC may issue the MAC-READY signal as 
described below.) Or, if there is no data in the LLC buffer for that address and channel, the MS-MAC may send the 
Null PDU. 

Otherwise, just before the transmission is due, the MS-MAC shall issue the MAC-READY signal to the LLC, 
announcing the current normal data segment size for advanced link data segments, the data categories for which a 
normal advanced link data segment may be sent in the current MAC block and the maximum available size of TM-SDU 
in this MAC block for appropriate data categories. 

NOTE 5: On a 25 kHz or 50 kHz QAM channel, the normal advanced link segment size is determined by the 
available space in a 4-QAM rate = V2 full-slot MAC block at the current bandwidth; on a 100 kHz or 
150 kHz QAM channel, the normal advanced link segment size is determined by the available space in 
half of a 4-QAM rate = Vi full-slot MAC block at the current bandwidth. 

NOTE 6: In the first MAC -READY signal in a reserved slot, the MS-MAC should allow normal advanced link data 
segments for all data categories. For a reserved subslot, the MS-MAC should indicate any data categories 
for which a normal advanced link segment would fit into the subslot using the modulation level and 
coding rate appropriate for that data category. 

Any TMA-UNITDATA request primitive issued by the LLC indicates the data category for the TM-SDU. 

i) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that fits within the MAC block 
using the modulation level and coding rate appropriate for the indicated data category then: 

for a full slot, a MAC-DATA or MAC-U-BLCK PDU shall carry that TM-SDU; use of MAC-U-BLCK 
is appropriate if the MS has an event label and the TM-SDU would occupy all, or most of, the 
MAC-U-BLCK PDU; 

for a subslot, a MAC-ACCESS PDU shall carry that TM-SDU. 

NOTE 7: The implicit length of the MAC-U-BLCK PDU on a QAM channel is set to correspond to the size of a 
normal advanced link data segment. 

If there is still space within the MAC block for another PDU by association, the MS-MAC may repeat the 
MAC -READ Y/TMA-UNITD ATA exchange process as required until there is not space for another MAC 
header. 

In the second (and subsequent) MAC-READY signal for a MAC block, the MS-MAC shall indicate the data 
categories for which a normal advanced link data segment may be sent in the current MAC block, the data 
categories for which a TM-SDU may be sent and the maximum available size of TM-SDU in this MAC block 
for appropriate data categories. 
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EXAMPLE 2: On a 25 kHz or 50 kHz channel, if the first TM-SDU is a normal data segment that can be sent 

using 16-QAM rate = Vi, the MS-MAC should not invite any data (either a normal data segment or 
any other data) for data categories that must use 4-QAM rate = Vi. Similarly, on a 25 kHz or 
50 kHz channel, if the first TM-SDU is a normal data segment that can be sent using 64-QAM 
rate = Vi, the MS -MAC should not invite any data (either a normal data segment or any other data) 
for data categories that must use 4-QAM rate = Vi; however the MS -MAC may choose to invite 
data (either a normal data segment or any other data) for data categories that must use 16-QAM 
rate = Vi. 

If the second (or subsequent) TMA-UNITDATA request primitive indicates a data category for which a 
different modulation level and/or coding rate is appropriate, it is expected that the MS-MAC would normally 
use the lower (or lowest) of the modulation levels and/or coding rates. 

ii) If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that does not fit within the 
MAC block using the modulation level and coding rate appropriate for the indicated data category then the 
MAC -DATA PDU (for a full slot) or MAC-ACCESS PDU (for a subslot) shall carry a first fragment of the 
TM-SDU, using the fragmentation procedure and including a request for reserved capacity within the 
MAC-DATA or MAC-ACCESS PDU. 

iii) If the LLC does not issue a TMA-UNITDATA request primitive but the DATA-IN -BUFFER signal indicates 
that there is data to send then the MAC -DAT A or MAC- ACCESS PDU shall contain a request for reserved 
capacity but shall not carry a TM-SDU. This case should not occur for the first PDU in a reserved full slot. 

After performing the above process, the MS-MAC should use the appropriate modulation level and coding rate 
according to the data category (or categories) of the PDU(s) but with the following exception: if the PDU(s) would 
actually fit within a MAC block using a lower modulation and/or coding rate, the MS -MAC shall use that lower 
modulation level and/or coding rate. 

NOTE 8: The above procedure relates to the protocol model of the interface with the LLC and does not imply any 
specific implementation. It may be noted that: 

■ on a 25 kHz or 50 kHz QAM channel, two, four, three, four or six advanced link data segments can 
be sent by association within a full slot when using 16-QAM rate = Vi, 16-QAM rate = 1, 64-QAM 
rate = Vi, 64-QAM rate = % or 64-QAM rate = 1 respectively; 

■ on a 100 kHz or 150 kHz QAM channel, two, four, eight, six, eight or twelve advanced link data 
segments can be sent by association within a full slot when using 4-QAM rate = Vi, 16-QAM 

rate = Vi, 16-QAM rate = 1, 64-QAM rate = Vi, 64-QAM rate = % or 64-QAM rate = 1 respectively. 

According to the protocol model, the data segments are provided by the LLC by using multiple 

MAC -READY and TMA-UNITDATA request exchanges. However implementers may choose to use a 

more optimized process. 

c) Stealing 

When the MS is transmitting in a circuit mode call on a 7i/4-DQPSK channel, and if there is data in the LLC buffer for 
that channel for which the stealing permission parameter indicates that stealing may be used, then the MS-MAC shall 
issue the MAC-READY signal to the LLC indicating: 

• the size of TM-SDU in this MAC block; and 

• the maximum valid size of TM-SDU, given any current stealing limitations. 

The fragmentation and association mechanisms may apply as described above for a 7i/4-DQPSK channel. If the LLC 
does not issue a TMA-UNITDATA request primitive, for example because the message is too long, then the MS-MAC 
shall not perform the stealing but may use the TMA-S AP procedures (i.e. random access and/or reserved access) to send 
the messages in the LLC buffer. 

NOTE 9: The MAC-U-BLCK PDU cannot be used on the steahng channel. 
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23.1 .2.1 .4 Priority, subscriber class and scheduled data information 

The TMA-UNITDATA request primitive includes the layer 2 PDU priority of the message, the stealing permission 
parameter and the subscriber class parameter. The DATA-IN-BUFFER signal indicates the maximum PDU priority and 
stealing permission parameter in the LLC queue. The DATA-IN-BUFFER signal may also indicate the maximum data 
priority parameter in the LLC queue and the amount of data in the LLC queue for each data priority (and for each data 
category on a D8PSK or QAM channel), and may indicate whether the next message to be sent is expected to contain 
packet data; the TMC-CONFIGURE request primitive may indicate the MS default data priority that the higher layers 
have negotiated with the SwMI. Also the DATA-IN-BUFFER signal provides information about whether all, some or 
none of the messages in the LLC queue are fully scheduled data and the lowest value of the maximum schedule interval 
for any fully scheduled data. The MS-MAC shall use these parameters as follows: 

i) The MS-MAC may need to use the PDU priority and subscriber class parameter from the TMA-UNITDATA 
request primitive in the random access procedure, if the BS has announced PDU priority or subscriber class 
restrictions on random access at this time. 

ii) The PDU priority information from the DATA-IN-BUFFER signal may also be used to cut short the reserved 
access waiting time-out if there is an emergency message in the LLC buffer, so that the MS may initiate the 
random access procedure. 

iii) The stealing permission parameter may be used to trigger the stealing mechanism. 

iv) The information about the maximum data priority and/or the amount of data in the LLC queue for each data 
priority, together with the MS default data priority, may be used by the MS -MAC to decide when to send its 
current short-term data priority requirements to the BS and the appropriate information to include. 

v) The information about whether the LLC currently expects that the next PDU to be sent will contain packet data 
may be used by the MS-MAC to decide whether it may initiate the random access procedure. 

vi) The information about scheduled data enables the MS-MAC to decide whether and when to use random access 
to request to send the data in the LLC buffer. 

There are eight possible levels of the layer 2 PDU priority, from the lowest priority 0, increasing to the highest 
priority 7 corresponding to an emergency message. 

There are eight defined levels of the data priority and MS default data priority, from the lowest priority 0, increasing to 
the highest priority 7. Also the data priority parameter may contain the value "undefined", and the MS default data 
priority parameter may contain the value "not applicable". 

There are 16 possible subscriber classes, allowing a population subdivision, e.g. for random access control. The 
operator defines the values and meaning of each class, and the MS may belong to one or more of those classes. The 
subscriber class parameter, as supplied in primitives from the higher layers, is a bit-mapped field which indicates, for 
each class, whether the MS belongs to that class. 

The stealing permission parameter defines whether the MAC may use stealing to send this message, if the MS is 
currently transmitting traffic on a 3i/4-DQPSK channel. It may have the following meanings: 

• stealing not required; 

• steal when convenient; 

• steal within time T.214; or 

• steal immediately. 

NOTE: If the MS is not transmitting traffic, the MAC ignores the stealing permission parameter. 
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23.1 .2.2 Services at the TMB-SAP 



The TMB-SAP shall be used for the transfer of un-addressed system broadcast messages. The primitives shall be 
TMB-SYNC, TMB-SYSINFO and TMB-SYSINFO-Q. The request primitive shall be used in the BS. The indication 
primitive shall be used in the MS to deliver the TM-SDU to the higher layers. 

The corresponding PDUs shall be the SYNC, SYSINFO and SYSINFO-Q PDU, the content of BSCH, BNCH and 
BNCH-Q respectively. Both PDUs contain many MAC elements, and also include a TM-SDU used by the MLE. 

NOTE: The SYNC and SYSINFO PDUs are used only on 7i/4-DQPSK and D8PSK channels. The SYSINFO-Q 
PDU is used only on QAM channels. 

23.1 .2.3 Services at the TMC-SAP 

The TMC-SAP shall be used for the transfer of local layer management information. It provides no data transfer 
services over the air interface. It shall be used, for example, for the higher layers to instruct the MAC to reconfigure its 
parameters, for the MLE to direct monitoring and scanning procedures in the MAC and for the MAC to issue reports on 
progress. 

23.1.2.4 Services at the TMD-SAP 

The TMD-SAP shall provide the interface between the MAC and the circuit mode U-plane application, e.g. the speech 
CODEC. It shall be used for the transfer of speech frames or circuit mode data. It shall also be used if the U-plane 
application steals from the traffic capacity to send encryption synchronization information and/or user-to-user signalling 
messages. 

NOTE: Circuit mode traffic transmission applies only on 7i/4-DQPSK channels. 

The TMD-UNITDATA request primitive from the U-plane application to the MAC shall be used when the U-plane 
application wishes to send data to the peer entity. 

The TMD-UNITDATA indication primitive from the MAC to the U-plane application shall be used to deliver data from 
the peer entity. 

There is also a TMD-REPORT indication primitive, which shall be used by the MAC to issue reports to the U-plane 
application e.g. when the MAC has stolen capacity from the traffic channel. 

23.1 .2.5 Use of endpoint identifiers 

The MS-MAC receives a common control channel, i.e. the MCCH or a common SCCH, unless directed by the BS to an 
assigned channel - assigned for a circuit mode call or for secondary control (see clause 23.3). A common control 
channel comprises one timeslot per TDMA frame whereas an assigned channel comprises one or more timeslots per 
TDMA frame. It is optional for an MS to be capable of using a multi-slot channel. 

NOTE 1: An assigned channel (either a single-slot or a multi-slot channel) may be a 7i/4-DQPSK, D8PSK or QAM 
channel. It is optional for an MS to be capable of using a D8PSK or QAM channel. 

The MS may be capable of processing only one channel at a time, either a common control channel or an assigned 
channel. 

Other MSs may be capable of processing more than one channel simultaneously, allowing concurrent MAC services to 
be provided. The "endpoint identifier" is a local identifier used to distinguish between multiple concurrent service 
instances. 

At the LLC-MAC boundary, the endpoint identifier shall refer to the use of a particular MAC channel, i.e. common 
control channel or assigned channel. It identifies the MAC channel to which a particular TMA-UNITDATA or 
TMD-UNITDATA or TLE-UNITDATA primitive (or DATA-IN-BUFFER or MAC-READY signal) applies. There 
shall be a unique correspondence between the endpoint identifier and the physical channel allocation used in the MAC 
(i.e. the timeslot for a single-slot channel or timeslots for a multi-slot channel). 

NOTE 2: This correspondence is known only within the MAC. The endpoint identifier is used by the higher layers 
as a label to refer to a particular MAC resource, so the MAC may change (i.e. replace) the actual physical 
allocation without changing the endpoint identifier. 
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NOTE 3: A MAC channel may carry both the advanced link and basic link signalling. For the purposes of the 

procedures for transmission and reception of signalling messages, the MAC does not generally make any 
distinction between advanced link and basic link messages. However, on a D8PSK or QAM channel, 
advanced link and basic link messages may be treated differently for link adaptation purposes. Also, on a 
QAM channel, the MAC is aware of the normal advanced link data segment size. 

23.1.3 MS capabilities 

The following clauses describe the capabilities of a frequency full duplex and half duplex MS. All MSs shall provide 
frequency half duplex capability while an MS may also provide fast switching capability or support frequency full 
duplex operation. 

23.1 .3.1 Frequency half duplex operation 

23.1.3.1.1 Frequency half duplex capability 

A frequency half duplex MS has the ability either to transmit on an uplink frequency or receive on a downlink 
frequency at any time. It is not able to transmit and receive at the same time. This type of MS also requires time to 
switch from its transmit to receive frequency. This shall be no more than a timeslot duration. 

Figure 23.2 shows the uplink and downlink slots of a single TDMA frame, with "x" marking an example of slots which 
can be used by a frequency half duplex MS. Only one downlink and the corresponding (same-numbered) uplink slot can 
be used in a single TDMA frame. If both the uplink and downlink slot in figure 23.2 are used by a single MS, time 
division duplex operation can be realized allowing a frequency half duplex MS to support single-slot duplex call 



X 



Figure 23.2: Frequency half duplex operation 

In the example shown, the MS can receive the downlink slot and also transmit in the corresponding uplink slot. It is also 
possible for a frequency half duplex MS to operate with a multi-slot channel. However, in this case, the BS should not 
send signalling messages to that MS when the MS is transmitting traffic or transmitting in reserved slots (or switching 
from receive to transmit or from transmit to receive). 

23. 1 .3. 1 .2 Fast switching capability 

A frequency half duplex MS may be capable of switching from transmit to receive, and from receive to transmit, 
between contiguous slots (e.g. capable of transmitting in uplink slot 2 and then receiving in the immediately following 
downlink slot 1). This type of MS is defined as a fast switching MS. A fast switching MS may fully support e.g.: 

• two concurrent single-slot channels; and/or 

• a two-slot duplex call service, 

provided that the BS allocates the two slots with adjacent numbers (i.e. slots 1 and 2, or 2 and 3, or 3 and 4, or 4 and 1). 
Figure 23.3 shows the uplink and downlink slots of a single TDMA frame, with "x" marking an example of slots which 
can be used by a fast switching MS. 

12 3 4 



X X 



X 


X 







Figure 23.3: Frequency half duplex operation with fast switching capability 
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NOTE: Fast switching capability on a 7i/4-DQPSK or D8PSK channel is indicated in the "class of MS" element; 
see clause 16. Fast switching capability on a QAM channel is indicated independently in the "extended 
capabilities" element; see clause 16. 

23.1 .3.2 Frequency full duplex operation 

A frequency frill duplex MS has the ability to transmit on an uplink frequency and receive on a downlink frequency at 
the same time. Therefore, this type of MS can use all timeslots in a TDMA frame. Figure 23.4 shows the uplink and 
downlink slots of a single TDMA frame, with "x" marking those slots which can be used by a frequency full duplex 
MS. Any combination of these slots may be used for a single call or for multiple calls. 

12 3 4 



Figure 23.4: Frequency full duplex operation 

23.1 .3.3 Basic capabilities of the physical layer 

The following performance is expected from the physical layer for a TETRA MS. 

An MS shall be capable of changing from one frequency to another frequency in less than 1 timeslot duration. 

An MS shall be capable of changing from reception to transmission or from transmission to reception in less than 
1 timeslot duration. 

An MS shall be capable of a combined frequency change and changing from reception to transmission or from 
transmission to reception in less than 1 timeslot duration. 

A fast switching MS shall be capable of changing from reception to transmission or from transmission to reception 
between contiguous timeslots. Fast switching capability is optional in the MS. 

NOTE 1: When changing from one frequency to another frequency, or when combining a frequency change with a 
change from reception to transmission or from transmission to reception, a fast switching MS operates 
like a normal frequency half duplex MS i.e. switching in less than 1 timeslot duration. 

A frequency full duplex MS shall be capable of changing reception or transmission frequency (or both) in less than 
1 timeslot duration. Frequency full duplex operation is optional in the MS. 

An MS should be capable of receiving and decoding the AACH in contiguous timeslots. An MS that is capable of 
operating on a QAM channel should be capable of receiving and decoding the AACH-Q in contiguous QAM timeslots. 

An MS may be capable of receiving or transmitting full slots of information in contiguous timeslots. 

NOTE 2: When changing from reception, the MS may need to receive the downlink beyond the start of the next slot 
in order to decode the current slot. Similarly, when changing to reception, the MS may need to start 
receiving the downlink before the start of the slot in order to decode that slot. This reduces the time 
available for the change to less than 14,167 ms. See clauses 7, 9.4.3.4 and 9.4.7.4 for the definition of the 
start of the slot. 
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23.1 .3.4 Modulation and bandwidth capabilities 

23.1.3.4.1 General 

There are three modulations modes for channels: 

• 7I/4-DQPSK (using 3i/4-DQPSK bursts); 

• D8PSK (using both 7i/4-DQPSK and 71/8-D8PSK bursts); and 

• QAM (using QAM bursts). 

In the case of a 3i/4-DQPSK or D8PSK channel, the bandwidth of the channel is 25 kHz. In the case of a QAM channel, 
the bandwidth of the channel may be 25 kHz, 50 kHz, 100 kHz or 150 kHz. 

23.1 .3.4.2 MS modulation and bandwidth capabilities 

An MS shall support 7i/4-DQPSK channels. An MS may support D8PSK channels (see note 2). An MS may support 
QAM channels (see note 3). 

If an MS supports QAM channels: 

• it is optional which QAM channel bandwidths the MS supports (see note 3); 

• the MS shall support transmission within random access uplink RF channel subslots (which have 
25 kHz bandwidth irrespective of the QAM channel bandwidth); 

NOTE 1 : This requirement applies even if the MS does not support 25 kHz QAM channels. 

• the MS shall support 4-QAM and 16-QAM, for both transmission and reception; 

• the MS may support 64-QAM (see note 3); 

• if the MS supports 64-QAM, it shall support either: 

64-QAM transmission and reception; or 
64-QAM reception only; 

• the MS shall support reception of the following combinations of modulation level and coding rate: 

4-QAM, coding rate = Vi; 
16-QAM, coding rate = Vr, and 
16-QAM, coding rate = 1; 

• the MS shall support transmission of the following combinations of modulation level and coding rate: 

4-QAM, coding rate = Vr, and 
16-QAM, coding rate = Vi; 

• the MS may support transmission of 16-QAM, coding rate = 1; 

• additionally, if the MS supports 64-QAM, it shall support reception of the following combinations of 
modulation level and coding rate: 

64-QAM, coding rate = Vr, 

64-QAM, coding rate = %; and 

64-QAM, coding rate = 1 ; 
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• if the MS supports 64-QAM for transmission, it shall support transmission of the following combinations of 
modulation level and coding rate: 

64-QAM, coding rate = Vi; and 

64-QAM, coding rate = %; 

the MS may support transmission of 64-QAM, coding rate = 1 . 

NOTE 2: This MS capabihty is indicated in the "class of MS" element in the U-LOCATION UPDATE DEMAND 
PDU; see clause 16. 

NOTE 3: These MS capabilities are indicated in the "extended capabilities" element in the U-LOCATION 
UPDATE DEMAND PDU; see clause 16. 

23.1 .3.4.3 BS modulation and bandwidth capabilities 

The BS shall support 7i/4-DQPSK channels. The BS may support D8PSK channels (see note 2). The BS may support 
QAM channels (see note 2). 

If the BS supports QAM channels: 

• it is optional which QAM channel bandwidths the BS supports and provides (see note 2); 

• the BS shall support reception of random access uplink RF channel subslots (which have 25 kHz bandwidth 
irrespective of the QAM channel bandwidth); 

NOTE 1 : This requirement applies even if the BS does not support 25 kHz QAM channels. 

• the BS shall support 4-QAM and 16-QAM, for both transmission and reception; 

• the BS may support 64-QAM (see note 3); 

• if the BS supports 64-QAM, it shall support either: 

64-QAM transmission and reception; or 
64-QAM reception only; 

• the BS shall support reception of the following combinations of modulation level and coding rate: 

4-QAM, coding rate = Vr, 
16-QAM, coding rate = Vr, and 
16-QAM, coding rate = 1; 

• the BS shall support transmission of the following combinations of modulation level and coding rate: 

4-QAM, coding rate = Vr, and 
16-QAM, coding rate = Vr, 

• the BS may support transmission of 16-QAM, coding rate = 1; 

• additionally, if the BS supports 64-QAM, it shall support reception of the following combinations of 
modulation level and coding rate: 

64-QAM, coding rate = Vr, 

64-QAM, coding rate = %; and 

64-QAM, coding rate = 1 ; 
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• if the BS supports 64-QAM for transmission, it shall support transmission of the following combinations of 
modulation level and coding rate: 

64-QAM, coding rate = Vi; and 

64-QAM, coding rate = %; 

the BS may support transmission of 64-QAM, coding rate = 1. 

NOTE 2: Support of these services is indicated in the "extended services broadcast" element in the S YSINFO and 
SYSINFO-Q PDUs; see clauses 21.4.4.1 and 21.4.4.1a. 

NOTE 3: The BS indicates the maximum modulation level that the MS is permitted to use on the uplink of a QAM 
assigned channel when it sends the channel allocation. 

23.1 .4 Services provided by tine LLC to tine MAC 

As described in clause 23.1, the MAC provides services to the LLC through the TMA-SAP, TMB-SAP and TMC-SAP 
(and to the U-plane application through the TMD-SAP). 

There may be an additional SAP between the LLC and the MAC: the TLE-S AP; this is the layer 2 signalling SAP. The 
LLC provides a data transfer service to the MAC through this SAP, for layer 2 signalling. Layer 2 signalling PDUs 
carry various types of general signalling information relating to layer 2 functions; the layer 2 signalling PDUs are 
treated as LLC PDUs in the PDU structures. 

The information transfer service provided by the LLC to the MAC is an unacknowledged service. 

NOTE 1 : However, if the LLC reports that the message transfer was successfully completed by random access, the 
MS-MAC can deduce that the message was received by the BS. 

The MAC may request the LLC to repeat a layer 2 signalling message, to increase the probability of a correct reception. 
On reception, the LLC does not suppress received duplicates. 

The LLC provides the layer 2 signalling service to the MAC using the following primitives: 

• the TLE-UNITDATA request primitive from the MAC to the LLC shall be used when the MAC wishes to 
send a layer 2 signalling message; 

• the TLE-UNITDATA indication primitive from the LLC to the MAC shall be used to deliver a layer 2 
signalling message corresponding to a MAC function; 

• the LLC shall report the progress of a request procedure locally to the MAC using the TLE-REPORT 
indication primitive; 

• the MAC may abort a TLE-UNITDATA request using the TLE-CANCEL request primitive. 

See clause 20 for a detailed description of the service primitives. 

The TLE-S AP boundary is defined to clarify the protocol description and does not imply any specific implementation. 
The word "shall" is used to describe this SAP and the primitives for traceability reasons in the protocol model, but they 
are not testable. 

When the LLC sends or receives a layer 2 signalling PDU, it uses the data transfer service offered by the MAC at the 
TMA-SAP (similar to the procedures when the LLC sends a PDU as a result of receiving a basic link TL-UNITDATA 
request primitive from the MLE). 

NOTE 2: Therefore, when the MAC wishes to send a layer 2 signalling message, the following process applies 
according to the protocol model: 

■ the MAC issues a TLE-UNITDATA request primitive to the LLC containing the information to be 
sent in the layer 2 signalling PDU; 

■ the LLC indicates to the MAC that there is data to be sent, using the DATA-IN-BUFFER signal; 
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■ on receipt of an appropriate MAC-READY signal from the MAC, the LLC forms the layer 2 
signalling PDU and issues it to the MAC in a TMA-UNITDATA request primitive; this process 
may be repeated (in different MAC blocks) if the PDU is to be sent more than once; 

■ on receipt of TMA-REPORT indication primitive(s) from the MAC relating to the layer 2 
signalling PDU, the LLC issues TLB-REPORT indication primitive(s) to the MAC in order to 
report the progress or result of the procedure; 

■ on receipt of a TLE-CANCEL request primitive from the MAC, the LLC issues a TMA -CANCEL 
request primitive (if the LLC has issued the message to the MAC); the LLC indicates the result of 
the cancellation to the MAC using the TLE-REPORT indication primitive. 

In the case of reception of a layer 2 signalling message, the following process applies: 

■ the MAC issues a TMA-UNITDATA indication primitive to the LLC to deliver a received 
TM-SDU; 

■ if the received LLC PDU is a layer 2 signalling PDU corresponding to a MAC function, the LLC 
delivers the information in the PDU to the MAC using a TLE-UNITDATA indication primitive. 

In the present document, the layer 2 signalling PDUs are used only for MAC functions - for data priority and link 
adaptation purposes: 

• the MS may send the L2 -DATA-PRIORITY PDU; see clause 23.4.7; 

• the MS may send the L2-LINK-FEEDBACK-INFO PDU; see clause 23.4.9; 

• the BS may send the L2-SCHEDULE-SYNC PDU; see clause 23.5.2.6; 

• the BS may send the L2-LINK-FEEDBACK-CONTROL or L2-LINK-FEEDBACK-INFO PDU; 

see clause 23.4.9. 

Also, the MS may send a combined L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITY PDU; 
however, for the purposes of the protocol model, the combining is performed by the LLC (see clause 22.3.1.7.3) so the 
MS-MAC does not issue the combined message. 

NOTE 3: This does not imply any specific implementation. 

23.2 Services provided by the lower IVIAC, and channel modes 
23.2. 1 Services at the TIVIV-SAP 

In the protocol model, the MAC layer is divided into two sub-layers, i.e. upper and lower MAC, as described in 
clause 19. The lower MAC shall provide the following services to the upper MAC protocol: 

• transfer of MAC PDUs using suitable physical layer bursts in accordance with the chosen TDMA timeslot; 

• report of PDU transfer related exceptions; 

• signal strength measurement (i.e. RSSI); 

• channel coding and scrambling as described in clause 8: 

Cyclic Redundancy Check (CRC) calculation; 

Forward Error Correction (FEC) and interleaving of MAC blocks; 

scrambling and de-scrambling of MAC blocks; 

• on a 71/4-DQPSK or D8PSK channel: choice of training sequence and channel coding corresponding to the slot 
flag value and vice versa; 

• on a D8PSK channel: choice of training sequence corresponding to the modulation and vice versa; 
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• control of the transmitted power, frequency, frequency band, duplex spacing and precise time synchronization 
as described in clauses 6 and 10. 

The lower MAC provides these services to the upper MAC via the TMV-SAP using the TMV-UNITDATA and 
TMV-CONFIGURE primitives: 

• the TMV-UNITDATA request primitive shall be used to request the lower MAC to transmit a MAC block; 

• the TMV-UNITDATA indication primitive shall be used by the lower MAC to deliver a received MAC block; 

• the TMV-CONFIGURE primitive shall be used to provide the lower MAC with information about the 
configuration of the channel or about the format of a received slot. 

NOTE: More than one TMV-UNITDATA request primitive may be needed to supply the information to be 

transmitted in a single slot or subslot. Similarly, more than one TMV-UNITDATA indication primitive 
may be needed to deliver the information received in a single slot (or subslot for the BS). 

Tables 23.1 and 23.2 show the correspondence between the TMV-UNITDATA service primitives at the TMV-SAP and 
the associated parameters in the TMV-UNITDATA service primitive respectively. Table 23.3 shows the parameters in 
the TMV-CONFIGURE service primitive. 

Table 23.1 : Correspondence between the upper and lower MAC at the TMV-SAP 



Upper MAC Service Primitive 


Lower MAC Service Primitive (TMV-SAP) 


TIVIA-UNITDATA request or 
TIVIB-SYNC request (BS only) or 
TMB-SYSINFO request (BS only) or 
TMB-SYSINFO-Q request (BS only) or 
TMD-UNITDATA request 


TMV-UNITDATA request 


TMA-UNITDATA indication or 
TIVIB-SYNC indication (MS only) or 
TMB-SYSINFO indication (MS only) or 
TMB-SYSINFO-Q indication (MS only) or 
TMD-UNITDATA indication 


TMV-UNITDATA indication 



Table 23.2: Parameters used in the TMV-UNITDATA primitive 



Parameter 


Request 


Indication 


MAC block 


M 


M 


MAC block length (see note) 


M 


M 


Logical channel (see note) 


M 


M 


CRC pass/fail indication (see note) 


- 


M 


Scrambling code (see note) 


M 


- 


Report (see note) 


- 


C 


NOTE: Not sent over the air interface. 


Key: M: Mandatory; 
C: Conditional; 
-: Not used. 
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Table 23.3: Parameters used in the TMV-CONFIGURE primitive 



Parameter 


Request 
(see note) 


Confirm 
(see note) 


Information about channel 


C 


C 


QAIVI slot format 


C 


- 


Scrambling code for reception 


c 


- 


Energy economy or napping information 


c 


- 


Signalling or traffic mode 


c 


- 


Second half slot stolen 


c 


- 


TCH type and interleaving depth 


c 


- 


IVIonitoring pattern information 


c 


- 


NOTE: Not sent over the air interface. 


Key: IVI: Mandatory; 
C: Conditional; 
-: Not used. 



The TMV-SAP boundary is defined to clarify the protocol description and does not imply any specific MS 
implementation. The word "shall" is used to describe this SAP and the primitives for traceability reasons in the protocol 
model, but they are not testable. 

Many of the parameters exchanged at the TMV-SAP are not sent over the air interface but may be deduced from the 
physical layer transmission or reception. For example, the scrambling code is not sent as part of the information content, 
but modifies the information so that reception with a wrong scrambling code will generate an erroneous CRC and so the 
information will be discarded. On the contrary, reception with the correct scrambling code will only be affected by the 
transmission medium errors. 

The MAC block is the SDU from the upper MAC. The size of the MAC block shall be equal to the appropriate SDU 
size for the logical channel being used. For C-plane signalling, the upper MAC shall assure this size by 
fragmenting/associating suitably and by using the Null PDU and/or fill bits to make the MAC block up to the required 
size. The required size for MAC blocks that may contain TMA-SAP C-plane signalling is shown in tables 23.4 
and 23.5. 
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Table 23.4: Size of uplink lUIAC blocks that may contain TIVIA-SAP signalling 



Logical channel 


Size of MAC block [bits] 


SCH/HU 


92 


SCH/F 


268 


STCH 


124 


SCH-P8/HU 


148 


SCH-P8/F 


412 


SCH-Q/RA 


65 


SCH-Q/HU25-4H 


57 


SCH-Q/HU25-16H 


133 


SCH-Q/HU25-16U 


288 


SCH-Q/HU25-64H 


209 


SCH-Q/HU25-64M 


285 


SCH-Q/HU25-64U 


440 


SCH-Q/HU50-4H 


141 


SCH-Q/HU50-16H 


301 


SCH-Q/HU50-16U 


624 


SCH-Q/HU50-64H 


461 


SCH-Q/HU50-64M 


621 


SCH-Q/HU50-64U 


944 


SCH-Q/HU100-4H 


309 


SCH-Q/HU100-16H 


637 


SCH-Q/HU100-16U 


1 296 


SCH-Q/HU100-64H 


965 


SCH-Q/HU100-64M 


1 293 


SCH-Q/HU100-64U 


1 952 


SCH-Q/HU150-4H 


477 


SCH-Q/HU150-16H 


973 


SCH-Q/HU150-16U 


1 968 


SCH-Q/HU150-64H 


1 469 


SCH-Q/HU150-64M 


1 965 


SCH-Q/HU150-64U 


2 960 


SCH-Q/U25-4H 


181 


SCH-Q/U25-16H 


381 


SCH-Q/U25-16U 


784 


SCH-Q/U25-64H 


581 


SCH-Q/U25-64M 


781 


SCH-Q/U25-64U 


1 184 


SCH-Q/U50-4H 


389 


SCH-Q/U50-16H 


797 


SCH-Q/U50-16U 


1 616 


SCH-Q/U50-64H 


1 205 


SCH-Q/U50-64M 


1 613 


SCH-Q/U50-64U 


2 432 


SCH-Q/U100-4H 


805 


SCH-Q/U100-16H 


1 629 


SCH-Q/U100-16U 


3 280 


SCH-Q/U100-64H 


2 453 


SCH-Q/U100-64M 


3 277 


SCH-Q/U100-64U 


4 928 


SCH-Q/U150-4H 


1 221 


SCH-Q/U150-16H 


2 461 


SCH-Q/U150-16U 


4 944 


SCH-Q/U150-64H 


3 701 


SCH-Q/U150-64M 


4 941 


SCH-Q/U150-64U 


7 424 
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Table 23.5: Size of downlink lUIAC blocks that may contain TIUIA-SAP signalling 



Logical channel 


Size of MAC block [bits] 


SCH/F 


268 


SCH/HD 


124 


STCH 


124 


SCH-P8/F 


412 


SCH-P8/HD 


196 


SCH-Q/D25-4H 


185 


SCH-Q/D25-16H 


389 


SCH-Q/D25-16U 


800 


SCH-Q/D25-64H 


593 


SCH-Q/D25-64M 


797 


SCH-Q/D25-64U 


1 208 


SCH-Q/D50-4H 


421 


SCH-Q/D50-16H 


861 


SCH-Q/D50-16U 


1 744 


SCH-Q/D50-64H 


1 301 


SCH-Q/D50-64M 


1 741 


SCH-Q/D50-64U 


2 624 


SCH-Q/D100-4H 


893 


SCH-Q/D100-16H 


1 805 


SCH-Q/D100-16U 


3 632 


SCH-Q/D100-64H 


2717 


SCH-Q/D100-64M 


3 629 


SCH-Q/D100-64U 


5 456 


SCH-Q/D150-4H 


1 365 


SCH-Q/D150-16H 


2 749 


SCH-Q/D150-16U 


5 520 


SCH-Q/D150-64H 


4 133 


SCH-Q/D150-64M 


5517 


SCH-Q/D150-64U 


8 288 



For U-plane signalling on STCH, the MAC block shall comprise a single MAC-U-SIGNAL PDU. For TCH, the MAC 
block shall comprise a single MAC-TRAFFIC PDU. (For TCH/S, this PDU contains one or two speech frames and, for 
circuit mode data, it contains data equivalent to a full slot.) 

The scrambling code passed to the MAC by the MLE shall be a 24-bit field composed of the MCC and MNC as defined 
in EN 300 392-1 [6], clause 7. The MCC and MNC shall be part of the MLE information contained within the SYNC 
PDU broadcast by the BS on the BSCH. The upper MAC shall add to this a 6-bit colour code which shall be contained 
in the SYNC PDU. The combination of MCC, MNC and colour code shall make up the scrambling code which the 
upper MAC shall pass to the lower MAC via the TMV-SAP. This scrambling code shall correspond to the extended 
colour code used for scrambling and de-scrambling in the lower MAC as defined in clause 8. The scrambling code shall 
correspond to the 30-bit extended colour code e(l), e(2), ..., e(30) as shown in figure 23.5. 



10 bits 


14 bits 


6 bits 


Mobile Country Code (MCC) 


Mobile Network Code (MNC) 


Colour Code 


6(1) -6(10) 


e(11)-e(24) 


6(25) - 6(30) 


e(1) = msbofMCC 


e(11) = msbofMNC 


e(25) = msb of Colour Code 



Figure 23.5: Mapping of scrambling code to extended colour code 
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23.2.2 PDU mapping of the logical channels at the TMV-SAP 

Logical channel definitions are given in clause 9 and an overview of their use may be found in clause 19. 
Table 23.6 defines the mapping of the MAC PDUs defined in clause 21 onto the various logical channels. 

Table 23.6: Mapping of the MAC PDUs onto the logical channels 



MAC PDU 


Logical channel(s) 


Note 


ACCESS-ASSIGN 


AACH, AACH-Q 


MAC internal information 


ACCESS-DEFINE 


SCH/HD, SCH/F, STCH, SCH-P8/HD, SCH-P8/F, 
SCH-Q/D 




QAM-SLOTINFO 


SICH-Q/D, SICH-Q/U 




MAC-ACCESS 


SCH/HU, SCH-P8/HU, SCH-Q/RA, SCH-Q/HU 


TMA-SAP information 


MAC-END-HU 


SCH/HU, SCH-P8/HU, SCH-Q/HU 




MAC-DATA 


SCH/F, STCH, SCH-P8/F, SCH-Q/U 




MAC-U-BLCK 


SCH/F, SCH-P8/F, SCH-Q/U 




MAC-RESOURCE 


SCH/HD, SCH/F, STCH, SCH-P8/HD, SCH-P8/F, 
SCH-Q/D 




MAC-D-BLCK 


SCH/F, SCH-P8/F, SCH-Q/D 




MAC-FRAG 


SCH/HD, SCH/F, SCH-P8/HD, SCH-P8/F, 
SCH-Q/D, SCH-Q/U 




MAC-END 


SCH/HD, SCH/F, STCH, SCH-P8/HD, SCH-P8/F, 
SCH-Q/D, SCH-Q/U 




MAC-TRAFFIC 


TCH 


TMD-SAP information 


MAC-U-SIGNAL 


STCH 




SYNC 


BSCH 


TMB-SAP information 


SYSINFO 


BNCH on SCH/HD, STCH, SCH-P8/HD, 
SCH-P8/F 




SYSINFO-Q 


BNCH-Q on SCH-Q/D 





23.2.3 TT/4-DQPSK, D8PSK and QAM channels 

There are three possible modulation modes for channels: 

• 7I/4-DQPSK; 

• D8PSK; and 

• QAM. 

In the present document, the modulation mode of a common control channel is always 7i/4-DQPSK. An assigned 
channel may be allocated as a 7i/4-DQPSK, D8PSK or QAM channel. 

The general signalling operation with the three modulation modes is described in the remainder of this clause. 

a) n/4-DQPSK channel 

All signalling and data messages and traffic on a 3i/4-DQPSK channel shall be sent using n/4-DQPSK modulation. 
The bandwidth of a 7i/4-DQPSK channel is 25 kHz. 

b) D8PSK channel 

A "D8PSK channel" is the generic term for a channel on which signalling and data messages may be sent using either 
7I/4-DQPSK bursts or Ji/S-DSPSK bursts. The following restrictions apply: 

• Random access messages shall be sent using the 7i/4-DQPSK control uplink burst. 

• In frame 18, downlink slots for which (MN + TN) mod 4 = 1 or 3 shall be sent using 7i/4-DQPSK bursts. 
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NOTE 1: BSCH (containing the SYNC PDU) + SCH/HD is mapped on a D8PSK channel in frame 18 if 

(MN + TN) mod 4 = 3; BNCH (containing the SYSINFO PDU) is mapped on a D8PSK channel in 
frame 18 if (MN + TN) mod 4=1; see clause 9.5.2. If the SYSINFO PDU is sent in other slots on a 
D8PSK channel, the BS may use either a 7i/4-DQPSK burst or a 71/8-D8PSK burst. 

For downlink transmissions on a D8PSK channel in the assigned slots in frames 1 to 17, and in the assigned slots in 
frame 18 for which (MN + TN) mod 4 = 2 or 4, the BS chooses whether to use a 7i/4-DQPSK or 71/8-D8PSK burst on a 
slot-by-slot basis. A receiving MS shall determine whether a downlink slot contains a 7i/4-DQPSK normal downlink 
burst or a 31/8-D8PSK normal downlink burst by determining whether normal training sequence 1 or normal training 
sequence 2 uses the 7i/4-DQPSK form or the 71/8-D8PSK form (see clause 9.4.4.3.2). 

NOTE 2: Thus there are four possible normal training sequences on the downlink of a D8PSK channel: 

■ normal training sequence 1 using the 7i/4-DQPSK form, indicating one logical channel 
(e.g. SCH/F) on the blocks 1 and 2 of the 7i/4-DQPSK normal downlink burst; 

■ normal training sequence 2 using the 7i/4-DQPSK form, indicating two logical channels 
(e.g. SCH/HD + SCH/HD) on the blocks 1 and 2 of the 7i/4-DQPSK normal downlink burst; 

■ normal training sequence 1 using the 71/8-D8PSK form, indicating one logical channel 
(e.g. SCH-P8/F) on the blocks 1 and 2 of the 71/8-D8PSK normal downlink burst; 

■ normal training sequence 2 using the 71/8-D8PSK form, indicating two logical channels 

(e.g. SCH-P8/HD + SCH-P8/HD) on the blocks 1 and 2 of the 71/8-D8PSK normal downlink burst. 

NOTE 3: The ACCESS-ASSIGN PDU is sent using 7i/4-DQPSK modulation in all downlink slots i.e. in both 

3I/4-DQPSK and 31/8-D8PSK bursts (see clause 9.4.4.2). The ACCESS-ASSIGN PDU uses the AACH 
logical channel which is mapped onto the broadcast block. 

Similarly, for reserved slots and subslots on the uplink of a D8PSK channel, the transmitting MS shall choose whether 
to use a 7I/4-DQPSK or 71/8-D8PSK burst in each slot or subslot (see clause 23.4.9). Then: 

• the BS shall determine whether a reserved slot contains a 7t/4-DQPSK normal uplink burst or a 71/8-D8PSK 
normal uplink burst by determining whether the normal training sequence uses the 7i/4-DQPSK form or the 
7I/8-D8PSK form (see clause 9.4.4.3.2); 

• the BS shall determine whether a reserved subslot contains a 3i/4-DQPSK control uplink burst or a 31/8-D8PSK 
control uplink burst by determining whether the extended training sequence uses the 7i/4-DQPSK form or the 
7I/8-D8PSK form (see clause 9.4.4.3.3). 

The BS should look for a 7i/4-DQPSK control uplink burst in subslots that it has designated as being available for 
random access. 

In the present document, the only usage of D8PSK channels is for assigned SCCH (see clause 23.3.1.2.2). The BS 
indicates that an allocated channel is a D8PSK channel when it sends the channel allocation. 

The bandwidth of a D8PSK channel is 25 kHz. 

The BS may allocate D8PSK channel(s) on the same carrier as 7i/4-DQPSK channel(s), in different timeslots - either on 
the main carrier or on other carriers. 

c) QAM channel 

All signalling and data messages on a QAM channel shall be sent using QAM modulation. 

Signalling and data messages on a QAM channel may use various combinations of modulation level and coding rate as 
follows: 



• 



• 



4-QAM, coding rate = Vr, 
16-QAM, coding rate = Vi; 
16-QAM, coding rate = 1; 
64-QAM, coding rate = Vr, 
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• 64-QAM, coding rate = %; 

• 64-QAM, coding rate = 1 . 

All downlink bursts shall use the full bandwidth of the channel (25 kHz, 50 kHz, 100 kHz or 150 kHz). The BS shall 
choose which modulation level and coding rate to use for the SCH-Q/D on a slot-by-slot basis. 

NOTE 4: In the present document, there is no QAM Broadcast Synchronization Channel. There is a QAM 

Broadcast Network Channel BNCH-Q (containing the SYSINFO-Q PDU), sent on SCH-Q/D in any slot 
in frames 1 to 18. In the present document, there is no fixed mapping of BNCH-Q on a QAM channel. 

Downlink slots (except slots containing the BLCH-Q) contain the AACH-Q and SICH-Q/D logical channels, both of 
which always use 4-QAM, coding rate = Vi. The AACH-Q may contain the ACCESS-ASSIGN PDU (see 
clause 21.4.7). The SICH-Q/D contains the downlink QAM-SLOTINFO PDU (see clause 21.4.8.2). The downhnk 
QAM-SLOTINFO PDU indicates the format (including the modulation level and coding rate) of the remainder of the 
downlink slot in which it appears. 

For the purposes of the protocol description: when an MS receives a downlink slot, the following "two-stage" method 
applies for decoding the slot: 

• The lower MAC shall decode the AACH-Q and SICH-Q/D and pass the information to the upper MAC using 
TMV-UNITDATA indication primitives. 

• The upper MAC shall use the ACCESS-ASSIGN PDU (when included within the AACH-Q) as described in 
other clauses within clause 23. 

• The upper MAC shall process the QAM-SLOTINFO PDU. 

• If the upper MAC understands the value of the "slot format" element in the QAM-SLOTINFO PDU and the 
MS is capable of processing slots with the indicated format then: 

the upper MAC shall inform the lower MAC about the format (including the modulation level and 
coding rate) of the remainder of the slot, using the TMV-CONFIGURE request primitive; 

the lower MAC shall decode the SCH-Q/D and pass the information to the upper MAC using the 
TMV-UNITDATA indication primitive. 

Otherwise (i.e. if the upper MAC does not understand the value of the "slot format" element or the MS is not 
capable of processing slots with the indicated format) the upper MAC shall instruct the lower MAC not to 
continue processing the remainder of the slot, using the TMV-CONFIGURE request primitive. 

NOTE 5: The MS may perform error detection on the SICH-Q/D. If the SICH-Q/D is not decodeable, the MS 
designer may choose an appropriate method for attempting to process the remainder of the slot; for 
example, the MS might attempt to process the remainder of the slot as 4-QAM, coding rate = Vi. 
Alternatively the MS may decide not to continue processing the remainder of the slot. 

NOTE 6: The MS is required to perform error detection on the AACH-Q. The MS actions if the AACH-Q is not 
decodeable are specified in other clauses within clause 23. 

When the MS sends a random access message, it shall use the logical channel SCH-Q/RA. This logical channel uses 
4-QAM, coding rate = Vi in a random access uplink RF channel subslot with a 25 kHz bandwidth. 

Reserved uplink slots and subslots shall use the full bandwidth of the channel (25 kHz, 50 kHz, 100 kHz or 150 kHz). 
The transmitting MS shall choose which modulation level and coding rate to use for the SCH-Q/U in each slot or 
SCH-Q/HU in each subslot (see clause 23.4.9) - subject to the maximum uplink modulation level permitted by the BS. 

Reserved uplink slots and subslots contain the SICH-Q/U logical channel, which always uses 4-QAM, coding rate = '/i. 
The SICH-Q/U contains the upHnk QAM-SLOTINFO PDU (see clause 21.4.8.1). The uplink QAM-SLOTINFO PDU 
indicates the format (including the modulation level and coding rate) of the remainder of the uplink slot or subslot in 
which it appears. 

When an BS receives a reserved slot or subslot, it should use a "two-stage" method for decoding the slot - similar to the 
method described above for an MS (except that AACH-Q and the ACCESS-ASSIGN PDU do not apply on the upUnk). 
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In the present document, the only usage of QAM channels is for assigned SCCH (see clause 23.3.1.2.2). The BS 
indicates that an allocated channel is a QAM channel when it sends the channel allocation. It also indicates the 
bandwidth of the channel and the maximum QAM modulation level that the MS is permitted to use on the uplink. 

The BS should not allocate a QAM channel on the same carrier as 7i/4-DQPSK or D8PSK channel(s). 

23.3 Control channel usage 
23.3.1 Control channel types 

This clause describes the MS procedures for using control channels. 

23.3.1.1 MCCH 

In each cell, one 25 kHz RF carrier shall be defined as the main carrier frequency which shall be broadcast in the 
SYSINFO PDU on the Broadcast Network Channel BNCH (or, on a QAM channel, in the SYSINFO-Q PDU on the 
QAM Broadcast Network Channel BNCH-Q). The MCCH shall occupy slot 1 of the main carrier frequency of a BS in 
normal mode. An MS shall locate and receive the downlink MCCH, unless the BS has allocated any common SCCHs. 

Signalling and data messages on the MCCH are sent using 3i/4-DQPSK modulation. 

The BS shall use SCH/HD, SCH/F, BNCH and BSCH for transmitting signalling and data messages on the downlink of 
the MCCH. An MS shall attempt to receive and decode any paging messages on the downlink MCCH addressed to that 
individual MS or to one of the MS's valid group addresses. An MS shall also attempt to receive and decode any 
broadcast signalling messages sent on the downlink of the MCCH. 

NOTE: Energy economy or dual watch mode and the cell reselection procedures may take precedence over the 

requirements on the MS to attempt to receive and decode paging messages and broadcast messages on the 
MCCH, or on a common SCCH. 

For uplink access on the MCCH, the MS shall follow the random access and reserved access procedures described in 
clauses 23.5. 1 and 23.5.2 respectively. The MS shall use SCH/HU for random access on the uplink of the MCCH and 
SCH/HU or SCH/F for reserved access on the uplink of the MCCH. The uplink shall occupy only a single slot per 
TDMA frame (i.e. slot 1) for reserved access but may use an extended uplink channel for random access purposes if 
indicated by the ACCESS-DEFINE or SYSINFO PDU. 

The downlink of the MCCH shall not be extended to more than a single slot per TDMA frame. A BS in normal mode 
shall always have an MCCH. However, a BS may assign the MCCH for use as a 7i/4-DQPSK traffic or assigned control 
channel in which case the BS enters minimum mode. 

The ACCESS-ASSIGN PDU in the AACH in frames 1 to 17 shall indicate common control in the downlink direction 
for an MCCH. The ACCESS-ASSIGN PDU in frames I to 17 for the MCCH shall contain one of the following: 

a) Header value = OO2: 

This is the normal case for an MCCH in which both the uplink and downlink are used for common 
control. "Field 1" shall indicate the access parameters for subslot 1 and "field 2" shall indicate the access 
parameters for subslot 2 of the uplink. 

b) Header value = OI2 and "field 1" = UMc (OOOOIO2): 

The BS may assign the uplink of the MCCH as a 7i/4-DQPSK assigned SCCH while still maintaining the 
MCCH on the downlink. In this case, the uplink may be shared between common control and assigned 
control. "Field 2" shall contain the access parameters for both of the uplink subslots and shall apply to 
both common and assigned control channels. 

c) Header value = IO2 and "field 1 " = UMc (OOOOIO2): 

This is the same as for case b) above except that the random access parameters in "field 2" shall apply 
only for MSs using the uplink for assigned control. Any MS in common control mode shall not use the 
uplink for random access in this case. 
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d) Header value = 1 Ij and "field 1 " = UMc (OOOOIO2) and "field 2" = UMt (xxxxxx2): 

The BS may assign the uplink of the MCCH for transmission of traffic while still maintaining the MCCH 
on the downlink. "Field 2" shall contain the traffic usage marker for the uplink assigned channel. 

e) Header value = 1 12 and "field 1 " = UMx (OOOOOO2) and "field 2" = UMx (OOOOOO2): 

The BS may indicate that the MCCH on its main carrier has been deallocated and is no longer available 
for downlink or uplink signalling purposes. If N. 215 successive ACCESS-ASSIGN PDUs received in 
frames 1 to 17 contain these values, then the MS-MAC should inform the MLE using a "common 
channel deallocated" TMC -REPORT indication primitive (indicating a downlink failure) in order to 
initiate the MLE cell reselection procedures. 

The ACCESS-ASSIGN PDU in the AACH for frame 18 shall only indicate the uplink access rights. During normal 
mode operation, it shall always be assumed that slot 1 on the downlink is for common control as part of the MCCH. 
Any of the possible header values may be used during frame 18 for an MCCH. 

23.3.1.2 SCCH 

The BS may designate a secondary control channel (SCCH) for use as a main control channel by a subset of the user 
population. Alternatively, an SCCH may be allocated to certain MSs for subsequent data transfer. These two cases will 
subsequently be referred to as common and assigned SCCHs respectively. 

23.3.1.2.1 Common SCCH 

The BS may operate up to three SCCHs for the purposes of common control signalling. Common SCCHs shall each 
occupy only one slot capacity on the main carrier and shall be used as the main control channel by a subset of the 
population. Therefore, a BS may operate up to a maximum of three common SCCHs in addition to the MCCH. 

Signalling and data messages on a common SCCH are sent using 7i/4-DQPSK modulation. 

The BS shall indicate the number of common SCCHs in operation on the main carrier by setting a two-bit field in the 
SYSINFO PDU transmitted on BNCH (or, on any QAM channels, in the SYSINFO-Q PDU transmitted on BNCH-Q). 
This two-bit field maps to the number of common SCCHs in operation on this BS. If no common SCCHs are in 
operation, only the MCCH in slot 1 shall be available for common control signalling on the main carrier. If one 
common SCCH is indicated by the SYSINFO (or SYSINFO-Q) PDU, then slot 2 of the main carrier shall be used for 
this SCCH. If two SCCHs are in operation, slots 2 and 3 shall be used and if three SCCHs are in operation, slots 2, 3 
and 4 shall be used. 

In idle mode, an MS shall receive either the MCCH (slot 1) or one of the common SCCHs on the main carrier. 
Therefore, an MS shall receive one of the four downlink slots on the main carrier for common control purposes. On 
registration or at subscription, an MS shall receive a parameter which indicates to the MS which one of the downlink 
slots on the main carrier shall be used. If an MS receives this value at subscription and then also is assigned a value at 
registration, the value given at registration shall be used. The following rule shall then be applied by the MS: 



• 



N_SCCH = number of common SCCHs in operation: 

two-bit field transmitted by BS in the SYSINFO (or SYSINFO-Q) PDU, value = 0..3; 

• MS_SCCH = MS SCCH allocation: 

four -bit field transmitted by BS to MS at registration or received by MS at subscription, 
value = to 11 (eleven); 

• Main carrier downUnk slot = 1 + (MS_SCCH mod (N_SCCH + 1)): 

value = 1 to 4; 

where mod = remainder after integer division. 

This rule shall enable the MS to derive the slot to be used on the main carrier from its MS_SCCH parameter received at 
registration or subscription and the number of common SCCHs currently in operation as indicated by the BS in the 
SYSINFO PDU. If the MS has not yet registered in this network and has no value from subscription, it shall use the 
MCCH (i.e. slot 1 on the main carrier). 
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NOTE: Subscription is applicable only for the MS's home network. 

The BS may change the number of common SCCHs by modifying the N_SCCH parameter. An MS shall decode the 
SYSINFO PDU and recognize if N_SCCH has changed. If N_SCCH has changed the MS shall re-calculate, according 
to the above rule, the main carrier slot that it should use for common control signalling. When decreasing the number of 
common control channels the BS shall not change its SCCH configuration before first transmitting the new 
configuration in the SYSINFO PDU. When increasing the number of common control channels the BS shall change its 
SCCH configuration and then transmit the new configuration in the SYSINFO PDU. 

A common SCCH, like the MCCH, shall always occupy only 1 slot per TDMA frame on the downlink of the main 
carrier. The uplink shall occupy only 1 slot per TDMA frame for reserved access but may use an extended uplink 
channel for random access purposes if indicated by the ACCESS-DEFINE or SYSINFO PDU (see clause 23.5.1 for 
more detailed explanation of random access procedures). 

An MS returning to the common control channel after, for example, a traffic channel assignment, shall return to the 
MCCH or common SCCH that it was using before the assignment unless it has received, in the meantime, a SYSINFO 
or SYSINFO-Q PDU indicating a change in the SCCH configuration. (An MS may return to the common control 
channel due to the MS deciding to leave the call or as a result of receiving a MAC-RESOURCE or MAC-END PDU 
with a "Timeslot assigned" value of OOOO2 to indicate that it should go to the MCCH or appropriate common SCCH.) In 
this case it shall return to the main carrier slot defined by the new configuration. When decreasing the number of 
common control channels the BS should transmit the SYSINFO PDU in all slots of frame 18 on7i/4-DQPSK and 
D8PSK channels, and should transmit the SYSINFO-Q PDU on any QAM channels, before changing the SCCH 
configuration to ensure that all MSs including those on assigned channels receive the configuration change. When 
increasing the number of common control channels the BS should change its SCCH configuration and then transmit the 
new configuration in the SYSINFO PDU (and in the SYSINFO-Q PDU on any QAM channels). 

The ACCESS-ASSIGN PDU for a common SCCH shall contain one of the combinations of elements a) to e) as 
described for the MCCH during frames 1 to 17 and shall follow the same rules defined for the MCCH for frame 18. 

23.3.1.2.2 Assigned SCCH 

An SCCH may be assigned by the BS for subsequent data transfer in response to an initial random access or after an 
initial paging message on the MCCH or on a common SCCH. This type of SCCH is referred to as an assigned SCCH. 
An MS shall be directed to an assigned SCCH by a MAC-RESOURCE or MAC -END PDU (see clause 21) transmitted 
by the BS. The assigned SCCH may be used by a certain group of MSs for a particular signalling message or data 
exchange (e.g. packet data); or it may be shared between several MSs each with intermittent bursts of signalling to send. 

NOTE 1: The BS may use an assigned SCCH as a general packet data channel supporting advanced links for 
several MSs, where each MS may be intermittently offering data packets. 

An assigned SCCH may be allocated as a 7i/4-DQPSK, D8PSK or QAM channel - as indicated by the "channel 
allocation" element in the MAC-RESOURCE or MAC -END PDU. The bandwidth of a 7i/4-DQPSK or D8PSK assigned 
SCCH is 25 kHz. The bandwidth of a QAM assigned SCCH may be 25 kHz, 50 kHz, 100 kHz or 150 kHz - as indicated 
by the "channel allocation" element in the MAC-RESOURCE or MAC -END PDU. 

An assigned SCCH may be allocated as occupying up to four slots per TDMA frame as indicated by the 
MAC-RESOURCE or MAC-END PDU. If both the uplink and downlink are assigned for this purpose then the uplink 
for reserved access shall occupy the same-numbered slots as the downlink; i.e. an assigned SCCH cannot be allocated 
with a different number of slots for the uplink for reserved access and downlink. (An extended uplink channel may be 
used for random access purposes if indicated by the ACCESS-DEFINE PDU.) 

The number of slots allocated to a particular assigned SCCH by the BS may be increased or decreased by sending a 
MAC-RESOURCE (or MAC-END) PDU on the assigned SCCH. 

An MS shall attempt to receive and decode all downlink signalling transmitted by the BS on all allocated slots of an 
assigned SCCH (within the constraints of the napping procedures and the cell reselection procedures, and linearization 
and transmission requirements). Similarly, the MS may transmit uplink signalling on all allocated slots of the uplink of 
an assigned SCCH in accordance with the random access and reserved access procedures defined in clauses 23.5.1 
and 23.5.2 respectively. 
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NOTE 2: The MS may operate with muhi-slot channels without the need for the MS to support frequency full 
duplex operation. These MS capabilities are indicated in the mobile class ("class of MS" element, see 
clause 16). If an MS is not frequency full duplex and is operating on a multi-slot channel, the BS should 
not send signalling messages to that MS when the MS is transmitting in reserved slots or switching from 
receive to transmit or from transmit to receive. 

If the BS allocates an assigned SCCH on the downhnk, the ACCESS-ASSIGN PDU (when present) in frames 1 to 17 
shall contain a header value of OI2, IO2 or II2 and "field 1 " shall be equal to UMa (OOOOOI2). If the BS allocates an 
assigned SCCH in the uplink direction, the ACCESS-ASSIGN PDU (when present) in frames 1 to 17 shall contain a 
header value of OI2 or IO2 depending on whether the uplink is also to be shared with common control uplink accesses. 
For a unidirectional assigned SCCH, any control slots in the opposite direction shall also be part of the assigned SCCH 
for the purposes of applying the general procedures for transmission and reception of signalling messages. 

If the BS allocates an assigned SCCH in both directions, the ACCESS-ASSIGN PDU (when present) in frames 1 to 17 
shall contain a header value of OI2 or IO2 depending on whether the uplink is also to be shared with common control 
uplink accesses. 

NOTE 3: In the present document, a D8PSK or QAM assigned SCCH is always allocated in both directions. 

However, in future editions of the present document, the BS may be permitted to allocate a D8PSK or 
QAM assigned SCCH in only one direction. Therefore the MS should expect that a D8PSK or QAM 
assigned SCCH may be allocated in only one direction. 

The assigned slot(s) during frame 18 may be used for any combination of common or assigned control signalling on the 
downlink, and the ACCESS-ASSIGN PDU (when present) shall indicate the uplink access restrictions. 

NOTE 4: When sent on a 7i/4-DQPSK or D8PSK channel, the ACCESS-ASSIGN PDU uses the AACH logical 
channel; the ACCESS-ASSIGN PDU is sent by the BS in every downlink slot. 

When sent on a QAM channel, the ACCESS-ASSIGN PDU uses the AACH-Q logical channel. The 
AACH-Q is sent by the BS in every downlink slot of a QAM channel (except slots containing BLCH-Q). 
However the ACCESS-ASSIGN PDU is present in the AACH-Q only if the AACH-Q mode element is 
set to (see clause 21.4.7.1). In the present document, the BS should set the AACH-Q mode element to 0. 
However, in future editions of the present document, the BS may set the AACH-Q mode element to 1 in 
some slots. Therefore, the MS should expect that the ACCESS-ASSIGN PDU may not be present in the 
AACH-Q. 

The BS shall always transmit in the downlink slots of an assigned SCCH except during a BLCH or BLCH-Q. This 
applies even while there is no signalling information to send. (The BS may send broadcast PDUs (except the SYNC 
PDU) or Null PDUs during these times.) This is required in order for the MS to carry out correctly its channel 
maintenance procedures for an assigned channel. 

NOTE 5: The BS should send the SYNC PDU on a 7i/4-DQPSK common control channel or on a 3i/4-DQPSK or 
D8PSK assigned channel only in the defined positions, which are in frame 18 (see clause 9); this is 
because the SYNC PDU is sent with the synchronization training sequence. The SYNC PDU is not used 
on a QAM channel. 

23.3.1.3 ACCH 

An ACCH is a control channel associated with an assigned traffic channel. There shall be two types of ACCH 
dependent on the current usage of the assigned channel. When the uplink or downlink of the assigned channel are not in 
use for traffic, the corresponding assigned slots in frames 1 to 18 shall be available for control signalling. This control 
channel is known as a Fast Associated Control Channel (FACCH). When the assigned channel is carrying traffic either 
in the uplink or downlink direction, only frame 18 is available for control signalling in that direction. This control 
channel is known as a Slow Associated Control Channel (SACCH). 

NOTE 1 : A traffic channel may be allocated as bidirectional but sometimes may only carry traffic either in the 
uplink or downlink direction e.g. for an inter-site call. Then the opposite direction is a FACCH. In this 
case, therefore, a FACCH will be available in one direction and a SACCH in the other direction. 

NOTE 2: When an assigned channel is carrying traffic either in the uplink or downlink direction then, in addition to 
the SACCH in that direction, capacity may be "stolen" from the circuit in frames 1 to 17 for signalling 
purposes, without changing the mode of operation (see clause 23.8). Stealing uses the STCH logical 
channel, whereas the FACCH and SACCH are mapped onto SCH. 
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An ACCH shall have the same modulation as the associated traffic channel. Circuit mode traffic transmission applies 
only on 7i/4-DQPSK channels. Therefore signalling messages on an ACCH are sent using 7i/4-DQPSK modulation. 

An ACCH shall have the same number of slots per TDMA frame as the associated traffic channel. The uplink and 
downlink shall have an equal number of slots per TDMA frame (see note 3). Therefore, for a multi-slot traffic channel, 
the ACCH shall assume the same uplink and downlink slot allocation as assigned for the traffic channel (see note 3). 

NOTE 3: The exception is that an extended uplink channel may be used for random access purposes if indicated by 
the ACCESS-DEFINE PDU. 

A receiving MS shall attempt to receive and decode all of the downlink slots of an ACCH (within the constraints of the 
napping procedures and the cell reselection procedures, and linearization and transmission requirements) to receive any 
addressed messages from the BS for that MS. An MS shall also receive any broadcast messages on the downlink 
ACCH. 

As an option, if the BS indicates that frame 18 extension is allowed (indicated by the "frame 18 extension element" in 
the SYNC PDU), an MS may receive and decode PDUs on all four slots of frame 18. However, the MS should not 
attempt to reconstruct any fragmented PDUs on frame 18 slots other than the ACCH for that MS. This restriction 
applies because an MS cannot know in which slot subsequent fragments will be sent for slots other than the ACCH for 
that MS. The MS shall not attempt to use random access transmission on slots of frame 18 other than its own ACCH 
(unless permitted by the "timeslot pointer" element from its own ACCH). The application of the normal procedures for 
transmission and reception of signalling messages shall apply only to the ACCH (i.e. FACCH and/or S ACCH) as 
indicated by the "timeslot assigned" element in the channel allocation. 

An MS transmitting in traffic mode shall attempt to receive and decode downlink slots in frames 1 to 17 when required 
by the assigned monitoring pattern(s) (given with the channel allocation). This allows the BS to send signalling, for 
example using the STCH, to a transmitting MS. The MS shall only be expected to adhere to the assigned monitoring 
pattern(s) within its duplex and switching capability (see clause 23.3.1.4). 

An MS transmitting in traffic mode shall attempt to receive and decode the ACCH in frame 18 when required by the 
assigned monitoring pattern(s). For multi-slot operation, the MS shall attempt to receive and decode at least the highest 
numbered downlink slot allocated for the circuit mode call in frame 18. (The MS shall also be capable of transmitting in 
the highest numbered uplink slot in frame 18 in case it has to respond to a paging message from the BS.) Similarly, an 
MS receiving in traffic mode shall attempt to receive and decode at least the lowest numbered slot allocated for the 
circuit mode call in frame 18 for SACCH downlink signalling (and it shall be capable of transmitting uplink signalling 
during the lowest numbered slot in frame 18). 

NOTE 4: This means that the MS may operate with multi-slot channels without the need for the MS to support 
frequency full duplex operation. 

When the MS switches out of traffic mode, it shall attempt to receive and decode all allocated slots for downlink ACCH 
signalling (within the constraints of the napping procedures and the cell reselection procedures, and linearization and 
transmission requirements). Similarly, any of the allocated slots may be used for uplink signalling in accordance with 
the MAC random access and reserved access procedures. 

In the case of a downlink FACCH, the ACCESS-ASSIGN PDU in frames 1 to 17 shall contain a header value of OI2, 
IO2 or 1 12 and "field 1" shall be equal to UMa (OOOOOI2). In the case of an uplink FACCH, the ACCESS-ASSIGN 
PDU in frames 1 to 17 shall contain a header value of OI2 or IO2 depending on whether the uplink is also to be shared 
with common control uplink accesses. 

In the case of a bidirectional FACCH, the ACCESS-ASSIGN PDU in frames 1 to 17 shall contain a header value of OI2 
or IO2 depending on whether the uplink is also to be shared with common control uplink accesses. 

The ACCH in frame 18 may used for any combination of common or assigned control signalling on the downlink and 
the ACCESS-ASSIGN PDU shall indicate the uplink access restrictions. 

The BS shall always transmit in the downlink slots of an ACCH except during a BLCH. This applies even while there is 
no signalling information to send. (The BS may send broadcast PDUs (except the SYNC PDU) or Null PDUs during 
these times.) This is required in order for the MS to carry out correctly its channel maintenance procedures for an 
assigned channel. 
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23.3.1 .4 Monitoring pattern during multi-timeslot traffic operation 

The BS may allocate a multi-slot traffic channel for circuit mode data calls. Monitoring pattern information shall be 
given by the BS along with the channel allocation at call set-up. A transmitting MS shall attempt to receive and decode 
downlink slots according to the assigned monitoring pattern(s). This allows the BS to send signalling, for example using 
the STCH, to a transmitting MS. The MS shall only be expected to adhere to the assigned monitoring pattern(s) within 
its duplex and switching capability. A BS should take this into account when attempting to transmit downlink signalling 
to a transmitting MS on a multi-slot channel. An MS transmitting on multiple slots per TDMA frame without a duplex 
or fast switching capability shall not be expected to receive signalling on the downlink in between transmitted bursts on 
the uplink; therefore the BS should only use frame 18 (or the lowest numbered slot in frame 1 - see note 1) for 
signalling to that MS during transmission. 

NOTE 1: The MS will not always be able to receive the lowest numbered downlink slot in the frame I's indicated 
by the assigned monitoring pattern(s) e.g. when the MS linearizes or transmits in the highest numbered 
uplink slot in frame 18. 

The following requirements apply to reception in frames 1 to 17 by an MS with a duplex or fast switching capability: 

• when an MS with frequency full duplex capability is transmitting in traffic mode on a multi-slot channel, it 
shall attempt to receive and decode all the downlink slots of the assigned channel, in those frames required by 
the monitoring pattern(s); 

• when an MS with fast switching capability is transmitting in traffic mode on a multi-slot channel, it shall 
attempt to receive and decode any downlink slots of the assigned channel that it is capable of receiving, in 
those frames required by the monitoring pattern(s). 

In frame 18, the MS shall attempt to receive and decode at least the highest numbered downlink slot of the assigned 
channel, in those frames required by the monitoring pattern(s) (see clause 23.3.1.3). 

NOTE 2: Fast switching capability on a phase-modulated channel and frequency full duplex capability are indicated 
in the "class of MS" element (see clause 16). 

23.3.2 Discontinuous transmission 

In the continuous mode of operation, the BS shall transmit continuously on the main carrier except during a BLCH. (If 
there is no signalling information to send, the BS may send broadcast PDUs or Null PDUs.) On the other carriers: 

• for phase modulation carriers (i.e. carriers currently carrying 7i/4-DQPSK and/or D8PSK channel(s)), the BS 
may ramp down and up during slots on the unused physical channels; however, the inter-slot training sequence 
(i.e. normal training sequence 3) shall always be present and so this ramping down and up is transparent to the 
MS operation; 

• for QAM carriers (i.e. carriers currently carrying QAM channel(s)), the BS shall transmit continuously except 
during a BLCH-Q. 

The BS shall indicate continuous or discontinuous operation on phase modulation carriers by setting appropriately the 
"sharing mode" field broadcast in the SYNC PDU on the BSCH. Three modes of discontinuous transmission are 
defined: 

• carrier sharing; 

• MCCH sharing; and 

• traffic carrier sharing. 

These modes are described in the following clauses. 

Discontinuous operation on the main carrier may be used for the purposes of sharing the channel resources between a 
number of cells. It may be desired to allocate different slots on the main carrier to different cells for 7i/4-DQPSK or 
D8PSK channels. This is known as carrier sharing operation. Alternatively, it may be desired to share slot 1 of the main 
carrier between a number of cells. This is known as MCCH sharing. 
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Discontinuous operation on phase modulation carriers other than the main carrier may be used for the purposes of 
sharing traffic resources between a number of cells for 7i/4-DQPSK and D8PSK channels. This may apply if the BS 
uses either mode of discontinuous operation on the main carrier. Otherwise it may apply only to the phase modulation 
carriers other than the main carrier. This is known as traffic carrier sharing. 

NOTE: Irrespective of the value of the "sharing mode" field, the BS should transmit continuously on sectored 
phase modulation carriers (except during a BLCH), in order to allow MSs to perform sectored channel 
monitoring. 

QAM carriers shall not be shared between cells using traffic carrier sharing, irrespective of the value of the "sharing 
mode" field: when the BS is using a carrier for QAM, it shall transmit continuously on that carrier (except during a 
BLCH-Q). 

It is optional for the MS to implement the methods for operating with a BS that uses any of the discontinuous modes. 
The MS shall not attempt to obtain service from a BS that uses a discontinuous mode unless that MS is capable of 
performing the appropriate procedures. 

23.3.2.1 Carrier sharing operation 

Carrier sharing operation allows the four slots of the main carrier to be shared between up to four adjacent cells. For 
example, each of four cells may be allocated one of the four timeslots on the main carrier or each of two cells may be 
allocated two timeslots each. Interference is avoided by ensuring that all of the cells sharing the carrier do not transmit 
on the downlink at the same time implying that the BSs sharing the main carrier need to be synchronized in time. 

If the slot allocated to a BS is for use as a common control channel (i.e. MCCH or common SCCH), the BS shall 
transmit on the downlink in all frames for that slot (except during a BLCH). If the slot is for use as a traffic channel or 
assigned SCCH, the BS need not transmit on the downlink for that slot while it is not assigned. Indeed, a slot may be 
shared between a number of BSs for allocation as a traffic channel or as a 7i/4-DQPSK or D8PSK assigned SCCH. 

The slot, frame and multiframe numbering may be independent between the cells sharing the main carrier. This means 
that all cells sharing a carrier can have a slot 1 for use as the MCCH for that cell. 

Phase modulation carriers other than the main carrier may also be shared between adjacent cells for 7i/4-DQPSK and 
D8PSK channels. Therefore the MS designer should note that the BS may use discontinuous bursts on any of the phase 
modulation carriers of a carrier sharing cell. 

23.3.2.2 MCCH sharing operation 

MCCH sharing allows a number of adjacent cells to share slot 1 of the main carrier for MCCH signalling. Up to 36 cells 
may share the same MCCH. Each cell has a number of reserved frames during which only the BS for that cell may 
transmit on the downlink MCCH. The remaining frames which are not reserved by any of the BSs sharing the MCCH 
may be used as common frames during which any of the BSs may transmit. However the network shall schedule 
downlink transmissions on common frames to ensure that two BSs do not transmit during the same common frame. 

If the SYNC PDU indicates "MCCH sharing", the SYNC PDU shall also indicate the number of reserved frames for 
this BS using the "TS reserved frames" field. The "TS reserved frames" field shall indicate the number of frames 
reserved over two multiframe periods as defined in clause 9. The BS shall transmit on the downlink during these 
reserved frames. 

During this mode of operation, the BSs shall also broadcast the location of the common frames by using the 
"TS_COMMON_FRAMES" field in the SYSINFO PDU sent on the BNCH. This field shall contain a bit map of the 
common frames for either the even-numbered or odd-numbered multiframes as indicated by the "Optional field flag". 

In order for this mode of operation to work successfully, the transmission of downlink bursts shall be synchronized in 
time between the BSs sharing the MCCH. In addition, slot numbering shall be synchronized between the BSs to ensure 
that they all have a common view of when downlink slot 1 is transmitted. However, frame and multiframe numbering 
shall be offset in order to avoid collision of bursts transmitted during reserved downlink slots. 

The remaining slots on the main carrier may be allocated as common SCCHs in which case the rules for reserved and 
common frames apply not only to slot 1 but also to those slots allocated as common SCCHs. Then the remaining slots 
not allocated for main or common secondary control may be shared between the BSs for use as traffic channels or as 
7t/4-DQPSK or D8PSK assigned SCCHs. This sharing is performed on a carrier sharing basis; the rules for reserved and 
common frames do not apply to assigned channels. A BS need not transmit during these slots if they are not assigned. 
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On a shared MCCH or common SCCH, the MS shall attempt to receive and decode the relevant slot during reserved 
frames for this BS and during those frames marked as common. It shall use the colour code received in the SYNC PDU 
on choosing a cell on which to camp in order to de-scramble the PDUs. This ensures that the MS cannot decode those 
transmissions during common frames on adjacent cells. In addition, the MS shall only use SYNC PDUs which contain 
the correct colour code for this cell since SYNC is not scrambled using the colour code meaning that an MS could 
receive SYNC from an adjacent cell. To prevent incorrect operation, only those with the correct colour code shall be 
interpreted by the MS . 

Phase modulation carriers other than the main carrier may be shared between adjacent cells for 7i/4-DQPSK and D8PSK 
channels (on a carrier sharing basis). Therefore the MS designer should note that the BS may use discontinuous bursts 
on any of the phase modulation carriers of an MCCH sharing cell. 

23.3.2.3 Traffic carrier sharing operation 

Traffic carrier sharing allows the four slots of phase modulation carriers other than the main carrier to be shared 
between adjacent cells for 7i/4-DQPSK and D8PSK channels. The BS shall transmit continuously on the main carrier 
(except during a BLCH). However, it may use discontinuous bursts on the other phase modulation carriers. 



23.3.3 Minimum mode operation 



Minimum mode operation allows a BS to allocate all four timeslots of the main carrier for traffic or assigned control 
purposes. Therefore, only frame 18 is available for common control. The following clauses describe the procedures for 
minimum mode operation which shall apply only to those MSs that are in common control mode and receiving the 
MCCH. They do not apply to MSs on an assigned channel (traffic or assigned secondary control). 

The BS should not allocate downlink slot 1 of the main carrier as a D8PSK channel. The BS should not allocate any 
timeslot of the main carrier as a QAM channel. 

23.3.3.1 Beginning of minimum mode or no service mode 

In the normal mode of operation, the MS shall receive the downlink of the MCCH and shall decode the AACH 
information (ACCESS-ASSIGN PDU). In the normal mode of operation, the MCCH is mapped to slot 1 of the main 
carrier frequency. The AACH in frames 1 to 17 shall indicate that downlink slot 1 is allocated for common control 
signalHng, with the header set to OO2 or "Field 1" set to UMc (OOOOIO2). 

The BS may choose to enter minimum mode by allocating slot 1 of the main carrier for some other 7i/4-DQPSK 
purpose. The AACH shall indicate that downlink slot 1 is no longer allocated for common control. 

If the AACH has header value = II2 and "field 1" = UMx (OOOOOO2) and "field 2" = UMx (OOOOOO2) then the BS is 
entering no service mode, and not entering minimum mode. 

All MSs in idle mode and currently receiving downlink slot 1 shall recognize when the system has entered minimum 
mode and should recognize when the system has entered no service mode. 

Minimum mode during frame 18 shall be assumed by an MS if the AACH indicates that downlink slot 1 in frame 17 is 
allocated for some purpose other than common control signalling unless the AACH is indicating UMx for no service 
mode. If the AACH cannot be decoded in frame 17, then the MS shall assume that the BS is in the mode indicated by 
the last correctly decoded AACH in a downlink slot 1. The BS shall not enter minimum mode in frame 18 but may only 
indicate the beginning of minimum mode in the AACH of frames 1 to 17. 

NOTE: In order to ensure robust operation, a BS may choose to enter minimum mode several frames before 

frame 18. This would ensure that all MSs have an increased probability of correctly decoding the AACH 
and taking the proper action during frame 18. 

The BS shall not enter minimum mode while there is future capacity already granted for reserved access on the MCCH. 
Thus the BS shall wait until any granted slots or subslots on the MCCH have been used (or released by the Null PDU) 
before entering minimum mode. 
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23.3.3.2 MS operation during frames 1 to 17 

During minimum mode, an MS shall receive slot 1 in frames 2 to 17 so that the BS may send signalling to an MS using 
the stealing channel or fast associated control channel. An MS shall decode the full contents of the slot to check whether 
the information is addressed to that MS. An MS shall decode the AACH in downlink slot 1 of frames 1 to 17 so that it 
can detect the end of minimum mode. If the end of minimum mode is detected, the MS shall also decode the full 
contents of that slot to check whether the signalling message contained is addressed to that MS (except if minimum 
mode ends in frame 1 in which case the BS should not assume that every MS is able to receive the full contents of the 
slot). An MS assigned to slot 1 during frame 18 in minimum mode shall decode the full contents of slot 1 in frame 1. 
All other MSs need only decode the AACH during slot 1 in frame 1. 

The BS should not assume that every MS is able to decode slot 1 of frame 1 since an MS assigned to slot 4 in frame 18 
may not be able to decode the following slot in frame 1 . 

23.3.3.3 MS operation during frame 1 8 

During minimum mode, an MS shall receive one of the four downlink slots in frame 1 8 as allocated to that MS at 
registration or subscription. An MS shall be allocated a minimum mode frame 18 slot at registration or subscription and 
shall receive that assigned downlink slot in frame 18 if the BS has entered minimum mode. The BS, therefore, may 
sub-divide the MS population at registration between the frame 18 slots for minimum mode operation according to 
whatever criteria it chooses to apply, or the sub-division may be applied at subscription of the MS population. If an MS 
has been assigned a minimum mode slot at subscription and then also receives a minimum mode slot at registration, the 
one received at registration shall be used. 

If the MS has not yet registered in this network and has no minimum mode slot from subscription then it shall use 
downlink slot 1 in frame 1 8 by default. 

NOTE 1: Subscription is applicable only for the MS's home network. 

NOTE 2: A BS may choose not to sub-divide the MS population in minimum mode, but instead may assign 
downlink slot 1 as the minimum mode frame 18 slot for all MSs. 

Frame 18 slots shall be shared between idle MSs for common control channel signalling and MSs on assigned channels 
which use frame 18 for associated control signalling. The BS may send downlink signalling messages on a downlink 
slot intended either for an idle MS receiving that slot or for an MS on the assigned channel using that slot for associated 
signalling. The BS shall indicate the destination for signalling messages with an address in the MAC header. 

NOTE 3: When an MS obeys a channel allocation command for an assigned channel, it may be permitted to 

continue to use the MCCH if it is capable of doing so (see clause 23.5.4). If the BS is in minimum mode, 
and if the assigned channel happens to correspond to the MS's minimum mode frame 18 slot, then there is 
a possible ambiguity of usage of the downlink slot in frame 18. If this occurs then the MS should not 
attempt concurrent random access on both the MCCH in minimum mode and the assigned channel. Also 
the BS should avoid sending ambiguous fragmented signalling in frame 18. 

Frame 18 downlink slots shall also be used for broadcast control signalling. The normal mapping of frame 18 downlink 
slots for BNCH and BSCH as specified in clause 9 shall apply. 

23.3.3.4 MS operation in energy economy or dual watch mode 

During minimum mode, an MS in energy economy or dual watch mode shall not modify its reception behaviour. An 
MS waking up to find that the system is in minimum mode shall not modify its reception behaviour. The BS may page 
an MS in energy economy or dual watch mode even during minimum mode by using the STCH or FACCH in the MS's 
"awake" frames. 

NOTE: If an MS in energy economy or dual watch mode on the MCCH perceives that the system is in minimum 
mode then, when it is required by clauses 23.7.6 or 23.7.7 to receive in frame 18, it receives and decodes 
slot 1. This applies even if the MS's nominal minimum mode frame 18 slot (as received at subscription or 
registration) is not slot 1 . 
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23.3.3.5 End of minimum mode 



During minimum mode, an MS shall continue to receive the AACH on downlink slot 1 of frames 1 to 17. If the AACH 
indicates that downlink slot 1 is allocated for common control purposes once again, the MS shall recognize that the BS 
is no longer in minimum mode and that normal mode operation has resumed. 

The BS shall not leave minimum mode while there is minimum mode capacity already granted for reserved access in 
slot 2, 3 or 4 of frame 18. Thus the BS shall wait until any slots or subslots granted in slot 2, 3 or 4 of frame 18 for MSs 
in common control mode have been used before leaving minimum mode. 

23.3.3.6 Restrictions on usage of minimum mode 

The minimum mode procedures are not applicable for a BS that uses MCCH sharing. 

The minimum mode procedures may apply for a BS that uses main carrier sharing. However, in this case, the MS shall 
always use downlink slot 1 in frame 18 as its minimum mode frame 18 slot, irrespective of any value received at 
subscription or registration. 

The minimum mode procedures apply only to those MSs that are in common control mode and receiving the MCCH. 
They do not apply to MSs on an assigned channel. Also, they do not apply to an MS that is receiving a common SCCH. 
If the AACH information indicates that the downlink slot is not being used for common control purposes, the MS 
should remain on its common SCCH unless the "number of common secondary control channels in use" field changes 
in the SYSINFO PDU (BNCH). 

It is optional for an MS to be capable of performing the minimum mode procedures. If the BS enters minimum mode, 
and the MS is not capable of performing the minimum mode procedures, then that MS will not receive service during 
minimum mode. The MS shall not attempt random access and need not decode slot 1 for signalling messages. The MS 
shall at least be able to recognize the beginning and end of minimum mode. 

23.3.4 Independent allocation of uplink and downlink 

A BS may allocate uplink and downlink channels for different purposes. This can apply to channels which are assigned 
for use as a traffic channel or control channel. For example, a traffic channel may be allocated in the downlink direction 
when there are only receiving mobiles for that cell and the corresponding uplink channel may be allocated for a call 
which only requires an uplink channel. The BS shall not allocate different modulation modes for the downlink channel 
and the corresponding uplink channel. 

NOTE 1: The above requirement restricts the BS from allocating different modulation modes for the downlink 

channel and the corresponding uplink channel. Note, however, that the D8PSK modulation mode refers to 
a channel on which signalling and data messages may be sent using either 7i/4-DQPSK or 31/8-D8PSK 
bursts. Therefore, on a D8PSK channel, both 7i/4-DQPSK and 71/8-D8PSK bursts may be used on both 
uplink and downlink. 

NOTE 2: In the present document, the only usage of D8PSK and QAM channels is for assigned SCCH, so 

independent allocation of uplink and downlink applies only for 7i/4-DQPSK channels. However, in future 
editions of the present document, the BS may be permitted to allocate a D8PSK or QAM assigned SCCH 
in only one direction. Therefore the MS should expect that a D8PSK or QAM assigned SCCH may be 
allocated in only one direction. 

Some examples are listed below: 

a) circuit mode call X on downlink channel; 
circuit mode call Y on uplink channel; 

b) circuit mode call on downlink channel; 
assigned SCCH on uplink channel; 

c) assigned SCCH on downlink channel; 
circuit mode call on uplink channel; 
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d) common control on downlink MCCH (slot 1); 

uplink slot 1 of main carrier allocated for a circuit mode call; 

e) downlink slot 1 of main carrier allocated for a circuit mode call; 

uplink slot 1 of main carrier available for common control. 

The allocation of uplink and downlink slots is indicated by the contents of the ACCESS-ASSIGN PDU, which is 
broadcast by the BS in every downlink slot on a 3i/4-DQPSK or D8PSK channel and may be broadcast in downlink slots 
on a QAM channel. All of the above examples can be accommodated with the available combinations of the header in 
the ACCESS-ASSIGN PDU (see clause 21 for more details). Also, when a channel is allocated, the "up/downlink 
assigned" or "up/downlink assigned for augmented channel allocation" element in the channel allocation shall inform 
the MS of any restrictions. 

However, for the application of the general procedures for transmission and reception of signalling messages, each 
control channel (ACCH or SCCH) shall be assumed to occupy any control slots on both the uplink and downlink 
directions, as indicated by the "timeslot assigned" element in the channel allocation. 

Therefore, for example, in case a), any ACCH in each direction shall be shared by the two unidirectional circuit mode 
calls. Similarly, in cases b) and c), the ACCH and SCCH shall be shared. In cases d) and e), the MSs in the circuit mode 
call shall share the common control channel. 

NOTE 3: In case a), the two calls X and Y generally involve different MSs. However, it is possible that they may 
be concurrent calls involving the same MS. 



23.3.5 Usage of a multi-slot channel 



A "channel" or "MAC channel", as used in the MAC protocol, means a common control channel or assigned channel. A 
common control channel comprises one timeslot per TDMA frame on a pair of radio carrier frequencies (downlink and 
uplink) so it equates with a physical channel; see clause 9.4.1. An assigned channel may comprise more than one 
timeslot per TDMA frame on a pair of radio carrier frequencies. It then corresponds to a combination of up to four 
physical channels, as indicated by the "timeslot assigned" element in the MAC-RESOURCE or MAC -END PDU that 
sent the MS to the channel. 

NOTE 1: A common control channel is a 7i/4-DQPSK channel. An assigned channel (either single-slot or 
multi-slot) may be a 3i/4-DQPSK, D8PSK or QAM channel. 

For the purposes of the procedures for transmission and reception of signalling messages on an assigned SCCH or an 
ACCH, all the slots comprising a multi-slot channel are equivalent. Downlink signalling messages (including 
continuation fragments and final fragments) may be sent on any downlink slot appropriate to that channel. Also, when 
the MS is counting slots on the channel (e.g. for the granting delay or for a reserved access allocation), all the slots 
appropriate to that channel shall be counted continuously. 

This contrasts with the method for a multi-slot circuit mode data service with interleaving depth N = 4 or 8. In this case, 
when the assigned channel is in traffic mode, multiple single-slot data TCHs (TCH/2,4 or TCH/4,8) shall be operated in 
parallel in order to obtain the multi-slot TCH transmission. The N-slot interleaving shall be performed within each 
single-slot TCH, such that interleaved blocks are separated by three timeslots. 

NOTE 2: The use of multiple single-slot data TCHs for the interleaving ensures that the performance of multi-slot 
circuit mode data is the same as that for single-slot circuit mode data with the same interleaving depth. 
This method applies only when the assigned channel is in traffic mode. When the channel is not being 
used for TCH, the channel reverts to FACCH and the normal signalling methods apply. 

23.3.6 Usage of a 50 kHz, 1 00 kHz or 1 50 kHz channel 

In the case of a 7i/4-DQPSK or D8PSK channel, the bandwidth of the channel is 25 kHz. 

In the case of a QAM channel, the bandwidth of the channel may be 25 kHz, 50 kHz, 100 kHz or 150 kHz - as indicated 
by the "channel allocation" element in the MAC-RESOURCE or MAC -END PDU. 
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For a wide-bandwidth channel, the SCH MAC blocks are larger than for a narrower channel. Apart from the SCH MAC 
blocks being larger: for the purposes of the transmission and reception of signalling messages, the bandwidth does not 
generally affect the MAC procedures with the following exceptions: 

• Random access messages are always sent using a 25 kHz bandwidth. (When an MS has chosen a subslot in an 
access frame and counted subslots to its chosen subslot in time using the same procedures as for a 25 kHz 
channel, it then makes a further random choice of which 25 kHz frequency block to use within the wider 
bandwidth; see clause 23.5.1.) 

• The normal advanced link data segment size depends on the bandwidth of the channel. (The MS-MAC informs 
the LLC of the normal advanced link data segment size when it issues the MAC-READY signal.) 

A wide-bandwidth channel may comprise more than one timeslot per TDMA frame, in which case clause 23.3.5 also 
applies. 

23.4 General MAC procedures 

23.4.1 PDU header analysis for signalling messages 

23.4.1.1 MAC PDU types 

The header of each MAC PDU enables the receiving MAC to interpret its contents correctly (see clause 21 for a full 
description of the PDUs). 

23.4.1 .2 Addressing at the TMA-SAP 

The TMA-SAP MAC headers generally contain an "Address" element and an element specifying the type of address. 
This layer 2 address is the source address for an uplink PDU, or the destination address for a downlink PDU. 

Another address (when needed) may be contained within the layer 3 part of the message e.g. the called address for an 
uplink PDU, or the calling address for a downlink PDU. The infrastructure makes the required address conversion 
between the uplink and downlink PDUs as appropriate. 

The usage of TETRA addresses and identities is described in EN 300 392-1 [6], clause 7. 

The address in the MAC header shall be a Short Subscriber Identity (SSI/USSI), a Short Management Identity (SMI) or 
an event label. An SSI/USSI is a 24-bit address specific to a particular TETRA network and is part of the complete 
TETRA Subscriber Identity (TSI). The 24-bit SMI is part of the TETRA Management Identity (TMI). An event label is 
a 10-bit MAC address that may be used to replace an SSI or SMI. 

The MS procedures throughout clause 23 apply to the requirements for a single TSI family. If an MS contains more 
than one TSI family (see EN 300 392-1 [6], clause 7), then each family shall meet the MAC protocol requirements 
independently of other families. 

23.4.1.2.1 Downlink message 

When the BS transmits a downlink MAC-RESOURCE PDU, it shall use one of the following addresses as appropriate 
as the destination address: 

an Individual Short Subscriber Identity (ISSI); 

an Alias Short Subscriber Identity (ASSI); 

an Un-exchanged Short Subscriber Identity (USSI), used only until a migrating MS has been assigned a valid 
address on this network; 

a Group Short Subscriber Identity (GSSI); 

a Short Management Identity (SMI); 

a vahd event label (see clause 23.4.1.2.3). 
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The "address type" element in the MAC header shall indicate whether the address is an SSI (ISSI/ASSI/GSSI), event 
label, USSI or SMI; and may be used to assign an event label (or a usage marker). 

When the BS transmits a MAC-D-BLCK PDU, it shall use a valid event label as the destination address. 

The receiving MS-MAC shall use the contents of a MAC -RESOURCE or MAC-D-BLCK PDU only if it recognizes the 
address as one of its own valid addresses or event labels. The one exception is that the MS-MAC shall process the MAC 
header in all received PDUs sufficiently to deduce the length of the PDU, in order to perform dissociation of multiple 
PDUs sent within a MAC block. 

If the MS-MAC receives a PDU with one of its valid addresses or event labels, it shall pass the TM-SDU to the LLC 
using the TMA-UNITDATA indication primitive. It shall indicate the received address and address type, unless the 
received address is an event label in which case the MS-MAC shall translate the event label into the corresponding SSI 
or SMI before passing the information to the LLC. 

NOTE 1: The other downlink TMA-SAP PDUs are used for continuations and end of a fragmented TM-SDU, and 
do not contain addressing information. 

NOTE 2: There is no distinction between an ISSI, ASSI or GSSI in the PDU. There is no distinction between an 
ISSI and an ASSI in the MAC. However, it is assumed that the MS-MAC knows which of its addresses 
are group addresses. The MS-MAC also knows which of its addresses is the SMI, and it knows whether 
an address is an USSI. 

NOTE 3: The predefined broadcast group address ("all ones" address), as described in EN 300 392-1 [6], clause 7, 
defines a group to which all MS belong. For example, it may be used as the destination address for 
CMCE or packet data calls, or it may be used by the BS for sending broadcast signalling messages using 
the services provided at the TLA-SAP and TMA-SAP. 

NOTE 4: After an ASSI has been allocated to the MS, the ISSI remains available and may still be used by the BS if 
required. The MS therefore continues to recognize its ISSI on the downlink. This applies only on a home 
network, and not in the case of migration when the MS does not have a valid ISSI for the network. 

23.4.1.2.2 Uplink message 

When the MS -MAC is required to send a C-plane message, it receives a TMA-UNITDATA request primitive from the 
LLC. This primitive shall contain the appropriate layer 2 address (the main address) and the address type. 

The main address in the request primitive shall be one of the following: 

• the MS's ISSI or ASSI for the network; 

• an USSI, used only by a migrating MS for the initial registration request; 

• a GSSI; 

• the SMI for the MS. 

When the MS-MAC forms a MAC-ACCESS or MAC -DATA PDU, it shall use the main address from the 
TMA-UNITDATA request primitive in the PDU "Address" element, unless an event label has been assigned for this 
address (see clause 23.4.1.2.3) in which case it may use the event label when appropriate. The "Address type" in the 
MAC header shall indicate whether the "Address" element contains an SSI (ISSI/ASSI/GSSI), event label, USSI or 
SMI. 

If an event label has been assigned for the main address, and fragmentation is not needed, the MS-MAC may optionally 
use a MAC-U-BLCK PDU instead of a MAC-DATA PDU - if the pre-defined length is appropriate (see 
clause 21.4.2.6) and the BS supports the MAC-U-BLCK PDU. 

NOTE 1: The other uplink TMA-SAP PDUs are used for continuations and end of a fragmented TM-SDU, and do 
not contain addressing information. 

NOTE 2: A group address in the MAC header is used on the uplink for the low level group presence indication (see 
clauses 22.2.1.3 and 22.3.1.2). This is the only case for which a group address is used in the MAC header 
on the uplink. 
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NOTE 3: After an ASSI has been allocated to the MS, and while it is still valid, that ASSI should be used in uplink 
messages in preference to the ISSI. 

23.4.1.2.3 Event labels 

An "event label" is a temporary shortened form of address which replaces a specified SSI (ISSI, ASSI or GSSI) or a 
specified SMI in the MAC PDUs, and is visible only at the MAC layer. It is valid only on one MAC channel. Its usage 
is illustrated in figure 23.6. 

Event label OOOOOOOOOO2 (all zeros) may be used by the BS for withdrawing an event label assignment (using "address 
type" IOI2 or 1 1 12). It is not valid for normal use. 

Event label 111111111 12 (all ones) may be used by the BS (with "address type" IOI2 or 1 1 12) to indicate that current 
event labels remain valid after a channel change. It is not valid for normal use. 

23.4.1 .2.3.1 General usage of event labels 

When the BS wishes to assign an event label, it shall use the MAC-RESOURCE PDU, which shall contain both the SSI 
(respectively SMI) and the assigned event label. 

a) If the BS includes an event label assignment in a MAC-RESOURCE PDU containing a non-fragmented 
message then: 

if the BS includes a "channel allocation" element in the MAC-RESOURCE PDU then the event label 
shall apply on the allocated channel (see note 1); 

otherwise the event label shall apply on the current channel. 

b) If the BS includes an event label assignment in the MAC-RESOURCE PDU of a fragmented message then the 
event label shall not apply until the associated MAC -END PDU has been received. Then: 

if the BS includes a "channel allocation" element in the MAC -END PDU then the event label shall apply 
on the allocated channel (see note 1); 

otherwise the event label shall apply on the current channel. 

If the MS discards the partially reconstructed TM-SDU (as described in clause 23.4.3.1.1) then it shall ignore 
the event label assignment. 

NOTE 1 : If the MS does not obey the channel allocation, it ignores the event label assignment. 

NOTE 2: For a channel allocation with "allocation type" = 1 12 (Replace + CSS channel), the event label applies 
only on the assigned channel, not on the CSS channel. (See clause 23.5.4 for a description of the 
allocation types.) 

The MS-MAC may then use the event label (if neither all zeros nor all ones) instead of the corresponding SSI 
(respectively SMI) as the source address in uplink PDUs sent on this channel; see figure 23.6. While the event label is 
valid, it may be used for both basic link and advanced link messages, and for random access, reserved access and 
STCH. 

NOTE 3: Thus, while the event label is valid, it may replace the SSI or SMI in any uplink PDUs sent on this 

channel. As defined in clause 23.3.5, all the slots comprising a multi-slot assigned channel are equivalent 
for the purposes of the general signalling procedures. Therefore an assigned event label applies to all slots 
of a multi-slot assigned channel. 

The BS may use the event label as the destination address in downlink PDUs (though the corresponding SSI or SMI 
may still be used). If the MS-MAC receives a downlink PDU containing a valid event label then it shall process the 
information contained in that PDU. The MS-MAC shall translate the event label into the corresponding SSI 
(respectively SMI) before passing the TM-SDU to the LLC. 
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The event label has a limited lifetime. The MS-MAC shall consider that an assigned event label is no longer valid in the 
following cases: 

1) A time T.201 has elapsed since the MS last received a downlink PDU containing that event label. Then the 
MS-MAC shall revert to using the SSI (respectively SMI). 

2) The MS receives another event label assignment (other than event label 1111111111 2) on this channel, for the 
same SSI (respectively SMI). Then, if the received event label is non-zero, the MS-MAC shall accept that new 
event label; if the received event label = 0, the MS-MAC shall revert to using the SSI (respectively SMI). 

3) The MS moves to another channel (unless the MS is leaving the channel as a result of a channel allocation 
message sent with "address type" 10l2or III2 and containing event label IIIIIIIIII2). Then the MS-MAC 

shall revert to using the SSI (respectively SMI), unless a new event label was assigned with the channel 
allocation. 

NOTE 4: In case 3), the MS discards an event label if it leaves the physical resource for which the event label was 
assigned i.e. the timeslot or timeslots on the appropriate carrier on this cell. The MS also discards an 
event label if the width of the channel (i.e. the number of timeslots allocated for the channel) is increased 
or decreased. As defined in clause 23.4.1.2.3.3, an exception to this definition occurs if the MS obeys a 
channel allocation command sent with "address type" IOI2 or III2 and containing event label 

IIIIIIIIII2. 

An event label is retained if a single-slot channel changes from common to assigned or from assigned to 
common. If the BS changes the number of common SCCHs then an event label is retained if the MS 
continues to use the same timeslot on the main carrier, but is discarded if the MS moves to a different 
timeslot. 

An event label is retained when the BS enters and leaves minimum mode even if the MS's minimum 
mode frame 18 slot is not slot 1. 

The BS is responsible for ensuring that it does not re-use an event label for another MS until the valid lifetime has 
expired. 

If the BS establishes or accepts an advanced link for the acknowledged service to carry TL-SDUs with a maximum 
length of 4 096 octets then, in the case of a 25 kHz QAM channel, the BS shall assign an event label for that MS 
address for use on that channel. Similarly, if the BS establishes an advanced link for the unacknowledged service to 
carry TL-SDUs with a maximum length of 4 096 octets then, in the case of a 25 kHz QAM channel, the BS shall assign 
an event label for that address for use on that channel. 

NOTE 5: Event label assignment is intended primarily for when an advanced Unk (or advanced links) have been set 
up for the appropriate address. However, its use is not precluded when there is only a basic link. 
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23.4.1.2.3.2 



Event Label (EL) 
allocation 

Figure 23.6: V+D air interface addressing 



Usage of event label all zeros 



As defined above, the BS may use event label to withdraw an event label assignment (using "address type" IOI2 or 
1 1 12 i.e. SSI/SMI + Event Label). Event label is not valid for use at other times. Thus it is not valid for use in 
downlink PDUs with "address type" OIO2 or in upHnk PDUs with "address type" Olj, or in MAC-D-BLCK or 
MAC-U-BLCK PDUs. If an MS receives a MAC-RESOURCE PDU with "address type" OlOj and event label = 0, or a 
MAC-D-BLCK PDU with event label = 0, it shall ignore the PDU; or, if the BS receives a MAC-ACCESS or 
MAC-DATA PDU with "address type" 01 2 and event label = 0, or a MAC-U-BLCK PDU with event label = 0, it shall 
ignore the PDU. 



23.4.1.2.3.3 



Usage of event label all ones 



When the BS sends a channel allocation, it may use "address type" IOI2 or III2 (i.e. SSI/SMI + Event Label) with the 
event label set to 11 11 11 11 II2 to indicate to those MS or MSs addressed by the SSI or SMI that their event labels from 
the current channel shall be valid on the allocated channel. For an MS addressed by the SSI/SMI, this indicates that all 
its event labels (for all its addresses) from the current channel shall be valid on the allocated channel - not only the 
event label corresponding to the SSI/SMI. 

NOTE 1: For a channel allocation with "allocation type" = OI2 (Add), the event labels from the current channel are 
then valid on both the current channel and the allocated channel. 

For a channel allocation with "allocation type" = 1 12 (Replace + CSS channel), the retention of event 
labels from the current channel applies only on the assigned channel, not on the CSS channel. 



£75/ 



739 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

NOTE 2: As an example: the BS could use "address type" IOI2 or 1 1 12 with event label llllllllll2ifit wishes 
to replace an assigned channel ("allocation type" = OO2) without invalidating the current event labels. This 
could apply if the BS wishes to change the width of the assigned channel (e.g. for a packet data channel 
PDCH) or if it wishes to replace the channel for any other reason. If the BS chooses to use the predefined 
broadcast group address (all ones SSI) then the replacement would apply to all the MSs on the current 
channel and would allow all the event labels from the current channel to remain valid on the new channel. 

If the BS uses "address type" IOI2 or 1 1 12 with event label 1 1 1 1 1 1 1 1 1 12 in a MAC-RESOURCE PDU containing a 
non-fragmented message then the event labels from the current channel shall apply on the channel allocated by the 
"channel allocation" element in the MAC-RESOURCE PDU. If the BS uses "address type" IOI2 or III2 with event 
label llllllllll2ina MAC-RESOURCE PDU containing a fragmented message then the event labels from the 

current channel shall apply on the channel allocated by the "channel allocation" element in the associated MAC -END 
PDU. 

If the MS either: 

• does not have any event labels on the current channel; or 

• does not obey the channel allocation; 

then it shall ignore the event label part of the MAC -RESOURCE PDU - obeying the other procedures within clause 23 
as if the PDU had been sent with "address type" OOI2 or IOO2. 

Event label llllllllll2is not valid for use at other times. Thus it is not valid for use in downlink PDUs unless there is 
an associated channel allocation. If an MS receives a MAC-RESOURCE PDU with "address type" IOI2 or 1 1 12 and 
event label IIIIIIIIII2 without receiving an associated channel allocation, it shall ignore the event label part of the 
PDU (obeying other procedures within clause 23 as if the PDU had been sent with "address type" OOI2 or IOO2). Also 
event label llllllllll2is not valid for use in downlink PDUs with "address type" OIO2 or in uplink PDUs with 
"address type" OI2, or in MAC-D-BLCK or MAC-U-BLCK PDUs. If an MS receives a MAC-RESOURCE PDU with 
"address type" OIO2 and event label = 1 11 1 11 1 1 1 12, or a MAC-D-BLCK PDU with event label = 11 1 1 1 1 1 1 II2, it shall 
ignore the PDU; or, if the BS receives a MAC-ACCESS or MAC-DATA PDU with "address type" OI2 and event 
label = 11 11 11 11 11 2, or a MAC-U-BLCK PDU with event label = 1 1 1 1 1 1 1 1 1 1 2, it shall ignore the PDU. 

23.4.1.2.4 Usage of SMI 

The SMI is an address specific to a particular TETRA network and is part of the complete TMI. The management 
identity can be used to address a particular piece of equipment independently from the subscriber identity. 

NOTE: The subscriber identities may be transferable, and may be removed from the equipment by the user. 

The SMI enables management functions to be performed over the air interface. Alternatively, if the infrastructure 
knows the correspondence between the equipment and the SSI, it may use the SSI for the management functions, since 
the management messages can be recognized by the MLE (see clause 18). 

The SMI may be numerically equal to an SSI attached either to that MS or to another MS. The SSI and SMI remain 
distinct because they can be distinguished by the address type in the MAC PDUs. 

23.4.1.2.5 Usage of USSI 

An USSI is the SSI of an MS from a foreign ITSI. It shall only be used in case of migration, when the MS does not have 
a valid ISSI or ASSI for the network, and shall only be used for the registration procedure. The USSI shall be equal to 
the ISSI used by the MS in its home network. 

When migrating into a network, the first message sent by an MS shall be a registration request, with the USSI as the 
layer 2 source address. The home MCC and MNC are included within the layer 3 part of the message. 

The USSI is then used on the downlink, in the BS response, as the layer 2 destination address. Also, if the layer 3 reply 
from the BS is not sent with the MAC response, the USSI will be used again as the layer 2 address when the BS sends 
the layer 3 reply. 
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The layer 3 reply to the registration request carries an ASSI for the visiting MS; that new SSI shall then be used by the 
MS inside the visited network. The allocated ASSI may be (by chance) equal to the USSI, but usually is not. 

Sometimes, the USSI may be numerically equal to an SSI or SMI already in use by another MS on the visited network. 
The signalling messages remain distinct because they can be distinguished by the address type in the MAC PDUs. 

Sometimes, the USSI may be numerically equal to the USSI of another migrating MS that is trying to register at the 
same time. In this case, the downlink signalling messages are not distinct at layer 2. However, the layer 3 reply from the 
BS contains the MS's home MCC and MNC, and the MM in the MS will discard a received reply if it has incorrect 
MCC or MNC (see clause 16). 

After the MS has received an ASSI, and has sent the LLC response if appropriate, usage of the USSI becomes invalid 
on this network for as long as the MS has a valid ASSI (see clause 16.4.7); the MS shall not use the USSI in uplink 
messages and shall not recognize the USSI in downlink messages. 

23.4.1 .3 Addressing at the TMB-SAP 

The characteristic of this SAP is that the broadcast information (system information) is implicitly addressed to every 
MS and, in order to keep the overhead as low as possible, does not contain an address field. The MAC PDU type under 
the TMB-SAP is distinct from those used under the TMA-SAP (see clause 21). The LLC shall be transparent for system 
broadcasts. No address is reported by the MAC to the MLE. 

NOTE: Broadcast messages under the TMB-SAP comprise only the SYNC PDU (i.e. content of BSCH), 
SYSINFO PDU (i.e. content of BNCH), SYSINFO-Q PDU (i.e. content of BNCH-Q) and 
ACCESS-DEFINE PDU. They should not be confused with signalling messages addressed to a group of 
MSs in the downlink using a specific group address at the TLA-SAP and TMA-SAP. Broadcast to all 
MSs in a cell or wider area may use the predefined broadcast group address ("all ones" address) and the 
services provided at the TLA-SAP and TMA-SAP (see clause 23.4.1.2.1). 

23.4.1 .4 Addressing at the TMD-SAP 

There is no addressing at the TMD-SAP. There may be multiple endpoints in the TMD-SAP which shall be associated 
with the corresponding CC instance and address used in the set-up phase in the user application. 

If the MAC steals from the circuit mode capacity to send C-plane signalling, it shall use TMA-SAP PDUs and 
addressing. 

23.4.2 PDU composition for signalling messages 

This clause describes the mechanisms whereby PDUs may be transmitted in the SCH MAC blocks. Three general 
mechanisms are provided: 

a) Fragmentation: 

This is the subdivision procedure that shall be used by an MS-MAC or BS in the case that a TM-SDU 
received from the LLC exceeds the available capacity in a MAC block. The transmission of the TM-SDU 
is then subdivided between two or more MAC blocks. 

b) Fill bit addition: 

The length of a MAC PDU is generally represented as a number of octets. In other cases the MAC PDU 
has an implicit length. "Fill bits" shall be used when the PDU does not fully occupy the indicated or 
implicit PDU length. They are used to make up the difference between the actual PDU content and the 
indicated or implicit length, and they also show the exact end of the TM-SDU. 

c) Association: 

This is the procedure that may be used by an MS or BS for sending two or more PDUs within a single 
MAC block. 

The reverse procedures (called reconstruction, fill bit deletion and dissociation respectively) are described in 

clause 23.4.3. 
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23.4.2.1 Fragmentation (TMA-SAP only) 

Fragmentation is the procedure that shall be used by an MS-MAC or BS in the case that a TM-SDU received from the 
LLC exceeds the available capacity in the MAC block. The MAC subdivides the TM-SDU into a number of fragments, 
where each fragment is sent within one MAC PDU. The whole TM-SDU contains only a single LLC header. This 
procedure is illustrated in figure 23.7. Fragments are not numbered, and so they shall be sent in sequence. If an error 
occurs during transmission then the MAC procedure fails (and the LLC has to request a re-transmission of the whole 
TM-SDU). From the point of view of the higher layers, the process is the same as if the TM-SDU had been transmitted 
in a single MAC block. 



LLC header 



TL-SDU 



TM-SDU 



MAC header TM-SDU (start) 



MAC header TM-SDU (cent.) 



MAC header TM-SDU (end) 



Figure 23.7: MAC fragmentation of a long TIVI-SDU 

The first fragment of a TM-SDU shall be sent with a full MAC header (MAC-RESOURCE PDU on the downlink, 
MAC-ACCESS or MAC -DATA PDU on the uplink). Whereas continuation fragments (MAC -FRAG PDU) and the 
final fragment (MAC -END or MAC-END-HU PDU) shall be sent with a reduced MAC header (see clause 21). In 
particular, only the full MAC header contains addressing information. 

Fragmentation applies only to subdivision of the actual TM-SDU. The MAC header cannot be subdivided between 
MAC blocks. 

On the downlink, the BS may temporarily interrupt a fragmented message to send other signalling whereas, on the 
uplink, the MS-MAC shall not interleave any other signalling with a fragmented TM-SDU. 

NOTE 1: The fragmentation procedure is intended primarily for use for basic link messages, if a TM-SDU exceeds 
the capacity of the MAC block. It is recommended that the MS/BS does not normally fragment advanced 
Unk messages. However fragmentation is needed on a D8PSK channel when an advanced link segment 
first sent using 71/8-D8PSK modulation is re-transmitted using 7i/4-DQPSK modulation. Fragmentation 
may also be needed for re-transmissions of advanced link segments after a reduction of bandwidth (for 
example, if the bandwidth of a QAM channel changes from 150 kHz to 50 kHz). 

NOTE 2: The fragmentation procedure is not intended for very long messages: 

a) It is recommended that fragmentation is not used for TL-SDUs that cannot be carried within a 
MAC-ACCESS PDU + four full slots. 

The capacity of MAC blocks depends on the modulation, and also the bandwidth and coding rate 
for QAM. The longest recommended size of TM-SDU and TL-SDU for use of fragmentation is 
shown in table 23.7 (in which it is assumed that the MAC- ACCESS PDU is sent by random access 
using an SSI and the full slots are sent using the indicated transmission method). For example, on a 
7I/4-DQPSK channel, it is recommended that fragmentation is not used for TM-SDUs exceeding 
1 106 bits; this corresponds to a TL-SDU of approximately 133 octets (if using ECS) or 137 octets 
(if not using ECS). 

b) The maximum permitted TM-SDU size is 2 632 bits (N.202), so fragmentation cannot be used for 
TL-SDUs exceeding approximately 324 octets (if using ECS) or 328 octets (if not using ECS). 

Instead, the MLE should set up an advanced link (or use an existing advanced link). 

It is recommended that the MLE uses the optional ECS if it sends long messages on the basic link 
(particularly if fragmentation is needed), but not when it sends short signalling messages. 
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NOTE 3: There is no MAC acknowledgement or MAC re-transmission of a fragmented TM-SDU. 
Acknowledgements and retransmissions are under the control of the LLC. 

Table 23.7: Longest recommended size of TM-SDU / TL-SDU for fragmentation 



Modulation and QAM coding 

rate and bandwidth for 

reserved access 


Longest recommended 
size of TM-SDU for 
fragmentation [bits] 


Approximate longest 
recommended size of 

TL-SDU for 
fragmentation [octets] 

if using FCS 


Approximate longest 
recommended size of 

TL-SDU for 

fragmentation [octets] 

if not using FCS 


TT/4-DQPSK 


1 106 


133 


137 


TT/8-D8PSK 


1 682 


205 


209 


4-QAM rate=1/2, 25 kHz 


731 


86 


90 


16-QAM rate=1/2, 25 kHz 


1 531 


186 


190 


16-QAM rate=1, 25 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


64-QAM rate=1/2, 25 kHz 


2 331 


286 


290 


64-QAM rate=2/3, 25 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


64-QAM rate=1, 25 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


4-QAM rate=1/2, 50 kHz 


1 563 


190 


194 


16-QAM rate=1/2, 50 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


16-QAM rate=1, 50 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


64-QAM rate=1/2, 50 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


64-QAM rate=2/3, 50 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


64-QAM rate=1, 50 kHz 


2 632 (see note) 


324 (see note) 


328 (see note) 


QAM, 100 kHz 

(any modulation level and rate) 


2 632 (see note) 


324 (see note) 


328 (see note) 


QAM, 150 kHz 

(any modulation level and rate) 


2 632 (see note) 


324 (see note) 


328 (see note) 


NOTE: This corresponds to the maximum permitted size of TM-SDU (N.202) 



23.4.2.1.1 



Fragmentation of downlink TM-SDU 



When the BS wishes to send a TM-SDU that does not require fragmentation, it shall send the entire TM-SDU within the 
MAC-RESOURCE PDU, or within the MAC-D-BLCK PDU (if the pre-defined length is appropriate and the 
MAC-D-BLCK PDU is supported by the addressed MS(s)). 

When the BS wishes to send a TM-SDU that exceeds the available capacity within a MAC block, it may subdivide the 
TM-SDU into fragments, which shall be sent on this control channel, in the following sequence: 

a) the first fragment shall be sent using the MAC-RESOURCE PDU; 

b) any continuation fragments shall be sent using n x MAC-FRAG PDUs (where n > 0); 

c) the final fragment shall be sent using the MAC -END PDU. 

Since the MAC -END PDU header is longer than the MAC-FRAG PDU header, there may be some cases when the 
remainder of the TM-SDU fits within MAC-FRAG but would not fit within MAC-END. In these cases, the BS should 
send the remaining data within MAC -FRAG (with fill bits if necessary) and then send an empty MAC-END PDU to 
complete the message. 

When the BS has sent one or more fragments of a fragmented message, it may temporarily interrupt the transmission if 
necessary to send a TMB-SAP broadcast message or a non-fragmented TMA-SAP message (but not a fragmented 
message). However the following points may be noted: 

• The MS-MAC receiving the fragmented message will discard a partially received TM-SDU if it does not 

receive a fragment in at least every N.203'th slot on this downlink control channel; see reconstruction by MS 
given in clause 23.4.3. LL 
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• The MS -MAC receiving the fragmented message will discard a partially received TM-SDU if it fails to decode 
an SCH MAC block on this control channel; see reconstruction by MS given in clause 23.4.3.1.1. Therefore, 
on a D8PSK channel, if the BS interrupts the transmission of a 7i/4-DQPSK fragmented message to send a 
non-fragmented message using 71/8-D8PSK modulation, this may cause the reconstruction of the fragmented 
message to fail (i.e. if the MS cannot currently receive SCH at the higher bit rate). Similarly, on a QAM 
channel, if the BS interrupts the transmission of a fragmented message to send a non-fragmented message 
using a higher modulation level and/or less coding, this may cause the reconstruction of the fragmented 
message to fail (i.e. if the MS cannot currently receive SCH at the higher bit rate). 

The MAC PDU structure allows only one first fragment or continuation fragment to be sent per MAC block. This shall 
be sent as the last PDU in the MAC block. In the MAC-RESOURCE PDU that contains the first fragment, the "Length 
indication" element shall be set to 11 11 II2. 

The BS may abort a fragmented transmission at any time before transmission of MAC-END by sending no more 
fragments of the message. 

If the BS wishes to send slot granting information with a fragmented message, the grant may be included in either the 
MAC-RESOURCE or the MAC-END PDU. 

If the BS wishes to send channel allocation information with a fragmented message, then this information shall be 
included within the MAC-END PDU and shall not be included within the MAC-RESOURCE PDU. 

NOTE: For a multi-slot control channel, all the downlink slots comprising that control channel are equivalent. In 
particular, the continuation and final fragments may be transmitted on any downlink slot appropriate to 
that channel (as indicated by the "Timeslot Assigned" element from the MAC-RESOURCE or 
MAC -END PDU that allocated the channel); they are not restricted to the same timeslot number as the 
first fragment. 

23.4.2.1 .2 Fragmentation of uplink TM-SDU 

When the MS -MAC wishes to send a TM-SDU that does not require fragmentation, it shall send the entire TM-SDU 
within the MAC-ACCESS PDU or the MAC-DATA PDU or the MAC-U-BLCK PDU (if supported by the BS). 
MAC-ACCESS applies if the MS-MAC is using random access or a subslot granted by the BS; MAC-DATA or 
MAC-U-BLCK applies if the MS-MAC is using a full slot granted by the BS. After transmission in a granted subslot or 
slot, the MS -MAC shall inform the LLC that the TM-SDU has been sent (using the TMA-REPORT indication 
primitive). 

The MS-MAC may perform fragmentation of a TM-SDU using any of the following transmission forms: 

i) MAC-ACCESS + MAC-END-HU; 

ii) MAC-ACCESS + nx MAC-FRAG + MAC-END < n < n^,^; 

iii) MAC-DATA + MAC-END-HU; 

iv) MAC-DATA + nx MAC-FRAG + MAC-END < n < n^^x- 

Form i) or ii) shall apply if the MS-MAC is using random access to start the process or if the MS-MAC is granted a 
subslot by the BS. Form iii) or iv) shall apply if the transmission starts in a full slot granted by the BS. 

NOTE 1 : The value of parameter n^ax depends on the modulation, and also the bandwidth and coding rate for 
QAM, to be used for the reserved access slot(s) containing the MAC-FRAG and MAC-END PDUs; 
see table 23.8. 

When the MS -MAC wishes to send a TM-SDU, it shall first determine whether fragmentation is required and, if so, the 
required capacity to carry the TM-SDU. 

For MAC-ACCESS, fragmentation is required for a TM-SDU exceeding: 

• 62 bits if sent by random access on a 7i/4-DQPSK or D8PSK channel; or 

• 35 bits if sent by random access on a QAM channel; or 

• Baccess bits if sent by reserved access (see note 2). 
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If fragmentation is required, the MAC-ACCESS PDU can carry a first fragment of: 

• 56 bits of TM-SDU if sent by random access on a 3i/4-DQPSK or D8PSK channel; or 

• 29 bits of TM-SDU if sent by random access on a QAM channel; or 

• (B ACCESS - 6) bits of TM-SDU if sent by reserved access (see note 2). 

NOTE 2: The value of parameter B access depends on the modulation, and also the bandwidth and coding rate for 
QAM, to be used for the reserved access subslot containing the MAC-ACCESS PDU; see table 23.8. 

NOTE 3: If the MS is on a QAM channel and is using random access to start the process of sending a TM-SDU 

exceeding 35 bits, but not exceeding Baccess bits for the modulation, bandwidth and coding to be used in 
a reserved access subslot, the MS may choose not to include a first fragment of TM-SDU in the random 
access message - instead just requesting a reserved subslot in the random access message and then 
sending the TM-SDU without fragmentation in the granted subslot. This may sometimes be more efficient 
for channels with high bandwidth. 

If the MS is on a D8PSK channel, and is using random access to start the process of sending a TM-SDU 
exceeding 62 bits, but not exceeding Baccess bits for 31/8-D8PSK, and if the MS intends to use 
71/8-D8PSK modulation in a reserved access subslot, the MS may choose not to include a first fragment of 
TM-SDU in the random access message - instead just requesting a reserved subslot in the random access 
message and then sending the TM-SDU without fragmentation in the granted subslot. 

For MAC-DATA, fragmentation is required for a TM-SDU exceeding Bdata bits (and the MAC-DATA PDU can carry 
a first fragment of B^ata bits of TM-SDU). 

NOTE 4: The value of parameter Bdata depends on the modulation, and also the bandwidth and coding rate for 
QAM, to be used for the reserved access slot containing the MAC -DATA PDU; see table 23.8. 

NOTE 5: The above numbers and the numbers in table 23.8 assume that the first fragment is the only PDU within 
the MAC block. If association has occurred within the subslot or slot, the available size is reduced 
correspondingly. Fragmentation can only be used after association if the complete MAC header, plus at 
least one bit of TM-SDU, can be sent within the MAC block. 

NOTE 6: The above numbers and the numbers in table 23.8 assume the use of an SSI or SMI in the MAC header. If 
an event label is used, then the available sizes are increased by 14 bits. 

If the remainder of the TM-SDU does not exceed Bend-hu bits, then the transmission can be completed with a single 
subslot (MAC-END-HU PDU). 

NOTE 7: The value of parameter Bend-hu depends on the modulation, and also the bandwidth and coding rate for 
QAM, to be used for the reserved access subslot containing the MAC-END-HU PDU; see table 23.8. 

Otherwise, the MS -MAC shall determine the required number (N = n H- 1) of full slots to send the remainder (R bits) of 
the TM-SDU: 

• ifR<BEND, N= 1; 

• if R > Bend, N = 2 + (R - Bend - 1) DIV Bfrag; 

where DIV represents integer division, rounded down. 

NOTE 8: The values of parameters Bfrag and Bend depend on the modulation, and also the bandwidth and coding 
rate for QAM, to be used for the reserved access slot(s) containing the MAC-FRAG and MAC-END 
PDUs; see table 23.8. 

It is not possible to indicate a reservation requirement in a MAC-FRAG PDU, so it will not normally be 
possible for the MS to change its decision about modulation and coding rate during transmission of the 
reserved slots containing the MAC -FRAG and MAC -END PDUs. Therefore, when performing 
fragmentation on a D8PSK or QAM channel, the MS-MAC first needs to decide on the modulation and 
coding rate that it will use for the transmission of the MAC-FRAG and MAC-END PDUs. It then 
calculates the required number of slots (N) based on that decision. 
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The MS-MAC shall use the following procedure for sending a fragmented TM-SDU: 

• The MS-MAC shall send the first fragment in the MAC-ACCESS or MAC-DATA PDU, setting the "fill bit 
indication" to indicate that no fill bits are present and the optional elements to include the "Capacity request" 
indicating: 

start of fragmentation; 

the reservation requirement for the remainder of the TM-SDU (and for any other messages which the MS 
has ready to send for this address on this control channel). 

• If the MS-MAC requested only a subslot then it shall send the final fragment in the first subslot or full slot 
granted for this address on this control channel (using MAC-END-HU or MAC-END respectively). The "fill 
bit indication" shall be used to indicate whether or not fill bits are used within the PDU. 

• If the MS-MAC requested one or more full slots then it shall send further fragments in full slots on this control 
channel, using n MAC-FRAG PDUs and then one MAC -END PDU. It shall send fragments in any slots 
already granted for this address, and in slots as they are granted by the BS for this address (in one or more slot 
grants). 

NOTE 9: The BS is permitted to use more than one slot grant when granting the requested slots for the further 
fragments, in which case the granted slots need not be continuous on this uplink control channel. 
However, see timer T.202 in procedure b) below. 

• For the first n-1 MAC -FRAG PDUs, the MS-MAC shall include fragments of Bfrag bits of the TM-SDU (with 
no fill bits). For the last MAC-FRAG, the MS-MAC shall include the next Bfrag bits of the TM-SDU, or the 
remainder of the TM-SDU if this is less than Bfrag bits (with the "fill bit indication" used to indicate the end 
of the user data). 

• The MS-MAC shall include the remaining part (if any) of the TM-SDU in the MAC -END PDU. The "fill bit 
indication" shall be used to indicate whether or not fill bits are used within the PDU. 

NOTE 10:The ISSI and its associated ASSI are equivalent for the purposes of the slot granting procedure (so the 
MS should use any subslot or slot(s) granted on its ISSI for a TM-SDU being sent with its ASSI, or vice 
versa). Similarly, an event label and its corresponding address are equivalent for the purposes of the slot 
granting procedure. Also, a newly assigned ASSI is equivalent to the replaced ASSI or USSI for the 
purposes of the slot granting procedure. 

The transmission process described above shall be continued until one of the following cases a) to d) occurs: 

a) The MS-MAC sends the MAC-END-HU or MAC-END PDU. 

The MS-MAC shall then inform the LLC that the TM-SDU has been sent by reserved access (using the 
TMA-REPORT indication primitive). 

The remainder (if any) of the MAC block shall be completed either by a Null PDU (plus fill bits) or by a 
MAC- ACCESS or a MAC-DATA or MAC-U-BLCK PDU by association as appropriate. 

If the MS has further signalling to send for this address on this control channel, then the MS-MAC shall 
include the reservation requirement in the MAC-END-HU/MAC-END PDU (or in the last PDU in the MAC 
block if association is performed). 

b) The MS-MAC does not have any capacity granted for this address on this control channel and a time T.202 has 
elapsed since: 

it last transmitted a fragment; or 

it last received a basic slot granting element for this address on this control channel containing the 
instruction to "Wait for another Slot Grant", 

whichever is the later. 

The MS-MAC shall then inform the LLC that the transmission has failed (using the TMA-REPORT indication 
primitive), and shall discard the TM-SDU. 

NOTE 1 1: After a fragmentation failure, the LLC is responsible for sending a re-transmission if appropriate. 
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c) The MS-MAC asked for fall slot reservation, and it receives a subslot grant for this address. 

The MS-MAC shall then inform the LLC that the transmission has failed (using the TMA-REPORT indication 
primitive), and shall discard the TM-SDU. The MS-MAC may use the granted subslot to send another 
TM-SDU. 

d) The MS-MAC receives a TMA-CANCEL request primitive from the LLC, cancelling transmission of this 
message. In this case, the MS-MAC shall discard the TM-SDU (reporting to the LLC that the message was not 
completely sent). 

If the MS-MAC is granted any further subslots or slots, it may send another TM-SDU. 

NOTE 12: Where procedures a), b) and c) use the expression "for this address", the ISSI and its associated ASSI are 
equivalent for the purposes of this procedure. Similarly, an event label and its corresponding address are 
equivalent for the purposes of this procedure. Also, a newly assigned ASSI is equivalent to the replaced 
ASSI or USSI for the purposes of this procedure. 

Table 23.8: Value of parameters in uplink fragmentation procedure 



Modulation and QAM coding 

rate and bandwidth for 

reserved access 


Hmax 


Baccess 


Bdata 


Bend-hu 


Bfrag 


Bend 


TT/4-DQPSK 


9 


62 


231 


85 


264 


258 


TT/8-D8PSK 


6 


118 


375 


141 


408 


402 


4-QAM rate=1/2, 25 kHz 


14 


27 


144 


50 


177 


171 


16-QAM rate=1/2, 25 kHz 


6 


103 


344 


126 


377 


371 


16-QAM rate=1, 25 kHz 


3 


258 


747 


281 


780 


774 


64-QAM rate=1/2, 25 kHz 


4 


179 


544 


202 


577 


571 


64-QAM rate=2/3, 25 kHz 


3 


255 


744 


278 


777 


771 


64-QAM rate=1 , 25 kHz 


2 


410 


1 147 


433 


1 180 


1 174 


4-QAM rate=1/2, 50 kHz 


6 


111 


352 


134 


385 


379 


16-QAM rate=1/2, 50 kHz 


3 


271 


760 


294 


793 


787 


16-QAM rate=1, 50 kHz 


1 


594 


1 579 


617 


1 612 


1 606 


64-QAM rate=1/2, 50 kHz 


2 


431 


1 168 


454 


1 201 


1 195 


64-QAM rate=2/3, 50 kHz 


1 


591 


1 576 


614 


1 609 


1 603 


64-QAM rate=1 , 50 kHz 


1 


914 


2 395 


937 


2 428 


2 422 


4-QAM rate=1/2, 100 kHz 


3 


279 


768 


302 


801 


795 


16-QAM rate=1/2, 100 kHz 


1 


607 


1 592 


630 


1 625 


1 619 


1 6-QAM rate=1 , 1 00 kHz 





1 266 


3 243 
(see note 1) 


1 289 


n/a 
(see note 2) 


3 270 


64-QAM rate=1/2, 100 kHz 


1 


935 


2 416 


958 


2 449 


2 443 


64-QAM rate=2/3, 100 kHz 





1 263 


3 240 
(see note 1) 


1 286 


n/a 
(see note 2) 


3 267 


64-QAM rate=1 , 1 00 kHz 





1 922 


4 891 
(see note 1) 


1 945 


n/a 
(see note 2) 


4918 


4-QAM rate=1/2, 150 kHz 


2 


447 


1 184 


470 


1 217 


1 211 


16-QAM rate=1/2, 150 kHz 


1 


943 


2 424 


966 


2 457 


2 451 


1 6-QAM rate=1 , 1 50 kHz 





1 938 


4 907 
(see note 1) 


1 961 


n/a 
(see note 2) 


4 934 


64-QAM rate=1/2, 150 kHz 





1 439 


3 664 
(see note 1) 


1 462 


n/a 
(see note 2) 


3 691 


64-QAM rate=2/3, 150 kHz 





1 935 


4 904 
(see note 1) 


1 958 


n/a 
(see note 2) 


4 931 


64-QAM rate=1 , 1 50 kHz 





2 930 
(see note 1) 


7 387 
(see note 1) 


2 953 


n/a 
(see note 2) 


7414 


NOTE 1 : In these cases, the complete subslot or slot can carry the maximum permitted size of TM-SDU. Therefore 
fragmentation will not be needed unless association has occurred within the subslot or slot, in which case 
the available size may have been reduced sufficiently for fragmentation to be appropriate. 

NOTE 2: In the cases of Bfrag for which "n/a" is indicated, a MAC-END PDU can always carry the remainder of the 
TM-SDU after the initial MAC-ACCESS or MAC-DATA, so use of MAC-FRAG is not appropriate. 
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23.4.2.1.3 Fragmentation in minimum mode 

Fragmentation is possible in minimum mode. However, long delays may be introduced, particularly for fragmentation 
over more than two MAC blocks. Therefore, an MS or BS may choose not to perform fragmentation during minimum 
mode, and the BS may (as always) choose not to grant slots to an MS for continuation of a fragmented message. 

When in minimum mode, the BS should not attempt fragmentation (other than within one slot on stealing channel 
STCH) of a message addressed to an MS that is in energy economy or dual watch mode. 

a) Downlink TM-SDU 

The general procedure for downlink fragmentation, described in clause 23.4.2.1.1, applies during minimum 
mode except that, when sending a fragmented message to an MS, the only MAC blocks that the BS may use 
for MAC -FRAG or MAC -END are those in the MS's designated minimum mode frame 18 slot. The MS-MAC 
receiving the fragmented message will discard a partially received TM-SDU if it does not receive a fragment 
in at least every N.203'th frame 18. 

NOTE 1: Not all MSs will receive all AACH blocks, so there is some uncertainly about exactly when a particular 

MS enters and leaves minimum mode. Therefore, if the BS is in process of sending a fragmented message 
when it enters or leaves minimum mode, it may prefer to abort the transmission. 

NOTE 2: The fragmentation procedure defined above applies only when the MAC -RESOURCE PDU is sent on 

SCH/F or SCH/HD (in slot 1 of frames 2 to 17 if the downlink is in FACCH or assigned SCCH, or in the 
MS's minimum mode frame 18 slot). If the MAC-RESOURCE PDU is sent on STCH then the 
fragmentation procedure defined in clause 23.4.2.1.7 apphes. 

b) Uplink TM-SDU 

During minimum mode, the MS-MAC shall follow the defined minimum mode rules for receiving and 
decoding the downlink for signalling messages (e.g. for receiving slot grants from the BS). 

The general procedure for uplink fragmentation, described in clause 23.4.2.1.2, applies (although, since time 
T.202 is counted in downlink signalling opportunities, in minimum mode the absolute time is 18 times its 
usual value). 

23.4.2.1 .4 Fragmentation on time-shared control channel 

a) Downlink TM-SDU 

The general procedure for downlink fragmentation, described in clause 23.4.2.1.1, applies on a time-shared 
MCCH except that, when sending a fragmented message to an MS, the only MAC blocks that the BS may use 
for MAC -FRAG or MAC-END are those in the reserved frames for this BS, not the common frames. The 
MS-MAC receiving the fragmented message will discard a partially received TM-SDU if it does not receive a 
fragment in at least every N.203'th reserved frame. 

b) Uplink TM-SDU 

On a time-shared MCCH, the MS-MAC shall follow the defined rules for receiving and decoding the 
downlink for signalling messages (e.g. for receiving slot grants from the BS). The normal procedure for uplink 
fragmentation, described in clause 23.4.2.1.2, applies (although, since time T.202 is counted in downlink 
signalling opportunities, on a time-shared control channel the absolute time is greater than on a 
non-time-shared channel). 

23.4.2.1 .5 Fragmentation on assigned channel if downlink is in SACCH 

a) Downlink TM-SDU 

In frames 1 to 17, fragmentation may be performed on the stealing channel within one slot (see 
clause 23.4.2.1.7). Fragmentation may also be performed on the SACCH in frame 18. 

NOTE 1: Long delays may be introduced for fragmentation over more than two frame 18s. Also, transmission of a 
fragmented message on SACCH should be aborted if the BS needs to send a fragmented message on the 
STCH of that assigned channel. Therefore, the BS may choose not to perform fragmentation on the 
SACCH in frame 18. 
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The general procedure for downlink fragmentation, described in clause 23.4.2.1.1, applies on the SACCH in 
frame 18 with the following differences: 

1) When sending a fragmented message on SACCH to an individual MS that is currently transmitting 
traffic on the uplink, the only MAC blocks that the BS may use for the message are those in the highest 
numbered downlink slot of the assigned channel, in those frame 18s that the MS is required to receive 
according to the assigned monitoring pattern(s). The MS-MAC receiving the fragmented message will 
discard a partially received TM-SDU if it does not receive a fragment in at least every N.203'th frame 18 
where it is required to receive. 

NOTE 2: The above procedure applies only for an individually addressed message. If the BS needs to send a group 
addressed fragmented message when the downlink is in traffic and an MS is transmitting traffic on the 
uplink then the BS follows procedure 2). 

NOTE 3: If the BS wishes to abort a fragmented transmission on SACCH to an individual MS that is currently 
transmitting traffic on the uplink, it should either wait for the appropriate number of multiframes 
(e.g. N.203 X 3 / number of monitoring patterns) before sending another fragmented message on SACCH 
or otherwise send a MAC-RESOURCE PDU indicating start of fragmentation in the highest numbered 
downlink slot of the assigned channel in a frame 18 where the MS is required to receive. 

2) When sending a fragmented message on SACCH to other MSs, the only MAC blocks that the BS may 
use for MAC-FRAG or MAC-END are those in the lowest numbered downlink slot of the assigned 
channel in frame 18. The MS-MAC receiving the fragmented message will discard a partially received 
TM-SDU if it does not receive a fragment in at least every N.203'th frame 18. 

NOTE 4: As defined in clause 23.3.1.3, an MS receiving in traffic mode on a multi-slot channel is normally 

required to receive only the lowest numbered slot in frame 18. Therefore, when sending a fragmented 
message on SACCH to MS(s) that are receiving in traffic mode on a multi-slot channel, the BS should 
send the first fragment in the lowest numbered slot of the assigned channel in frame 18. Continuation and 
final fragments sent on SACCH to any MS that is not transmitting traffic on the uplink may be sent only 
in the lowest numbered slot of the assigned channel in frame 18. 

NOTE 5: The BS should note the procedures used by an MS for reconstruction if the MS switches in or out of 

traffic transmit mode or sees the downlink leave SACCH (see clause 23.4.3.1.5, paragraph before note 1 
and paragraph before note 4). 

NOTE 6: In case of propagation errors, there is some uncertainly about exactly when a particular MS sees the 

channel enter or leave SACCH. Therefore, if the BS is in process of sending a fragmented message when 
it enters or leaves SACCH, it may prefer to abort the transmission. 

b) Uplink TM-SDU 

In frames 1 to 17, if an MS is transmitting traffic on the uplink then it may perform fragmentation on the 
stealing channel within one slot (see clause 23.4.2.1.7). 

Fragmentation may be performed by any MS on the uplink SACCH or FACCH. The general procedure for 
uplink fragmentation, described in clause 23.4.2.1.2, applies although, since time T.202 is counted in downlink 
signalling opportunities, the absolute time is 18 times its usual value. If a fragmentation on uplink SACCH is 
being performed by an MS that is transmitting traffic on the uplink then the absolute time of T.202 is also 
modified by the monitoring pattern(s). 

NOTE 7: Time T.202 is counted in downlink signalling opportunities. However, the BS may choose to send a slot 
grant by stealing from the downlink TCH. 
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23.4.2.1 .6 Fragmentation on assigned channel if downlini< is in FACCH or assigned SCCH 

a) Downlink TM-SDU 

The general procedure for downlink fragmentation, described in clause 23.4.2.1.1, applies when an assigned 
channel is not in downlink traffic with the following difference: 

When sending a fragmented message to an individual MS that is currently transmitting traffic on the 
uplink, the only MAC blocks that the BS may use for MAC-FRAG or MAC-END are those in the 
downlink slots where the MS is required to look for further fragments (as defined in clause 23.4.3.1.6 
procedure a). The MS-MAC receiving the fragmented message will discard a partially received TM-SDU 
if it does not receive a fragment in at least every N.203'th slot where it is required to look for further 
fragments. 

NOTE: The above procedure applies only for a message individually addressed to an MS that is currently 

transmitting traffic on the uplink. If the BS needs to send other fragmented messages when the downlink 
is not in traffic then the BS follows the general procedure for downlink fragmentation (so continuation 
and final fragments may be transmitted on any downlink slot appropriate to the assigned channel). This 
applies even if the uplink is in traffic. 

b) Uplink TM-SDU 

In frames 1 to 17, if an MS is transmitting traffic on the uplink then it may perform fragmentation on the 
stealing channel within one slot (see clause 23.4.2.1.7). 

Fragmentation may be performed by any MS on the uplink SACCH or FACCH. The general procedure for 
uplink fragmentation, described in clause 23.4.2.1.2, applies (although, if a fragmentation on uplink SACCH is 
being performed by an MS that is transmitting traffic on the uplink then the absolute time of T. 202 is modified 
by the monitoring pattern(s)). 

23.4.2.1 .7 Fragmentation on stealing channel 

On the stealing channel STCH, fragmentation is only permitted within one slot. Neither the MS nor the BS shall attempt 
to perform fragmentation over more than one stolen slot. 

The procedure for transmission on STCH (including fragmentation) is described in clause 23.8.4. 

23.4.2.2 Fill bit addition 

Fill bits shall be added when the actual size of the MAC PDU is: 

• for a MAC-U-BLCK or MAC-D-BLCK PDU: less than the implicit length of the PDU, or less than the 
available capacity of the MAC block; 

• for the other TMA-SAP PDUs: less than the PDU length indicated in the MAC header, or less than the 
available capacity of the MAC block. 

Fill bit addition applies only to TMA-SAP PDUs. 

If fill bits are added, the MAC shall set the "fill bit indication" in the MAC header to 1. In order to add fill bits within a 
PDU, the MAC shall: 

• add a bit " 1 " immediately following the last bit of the TM-SDU data; 

• complete as appropriate with bits set to "0": 

in the case of a MAC-U-BLCK or MAC-D-BLCK PDU, complete with the required number (> 0) of bits 
set to "0" until the size of the PDU corresponds to the implicit length or the available capacity of the 
MAC block (if that is less than the implicit length); 

in the case of the other TMA-SAP PDUs: 

■ if a length indication is included in the MAC header, then complete with the required number (> 0) 
of bits set to "0" until the size of the PDU corresponds to the indicated length or the available 
capacity of the MAC block (if that is less than the indicated length); 
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■ if a length indication is not included in the MAC header (or if the length indication is set to 
111 11 O2), then complete with the required number (> 0) of zeros to fill the MAC block. 

Fill bits inserted after a Null PDU to complete the MAC block shall be set to "0", except for the first bit after the Null 
PDU which shall be set to "1". 

When there is not enough space to insert a Null PDU in the remainder of a MAC block, the MAC block shall be 
completed such that the first bit after the user data shall be set to "1" and the following bits shall be set to "0". 

NOTE: In this procedure (i.e. when there is not enough space to insert a Null PDU), the MAC uses the normal 

method for indicating whether there are fill bits inserted within the last indicated or implicit PDU length. 
Thus, if the actual size of the last MAC PDU in the MAC block is less than the indicated or implicit PDU 
length then the MAC sets the "fill bit indication" to 1; if the actual size of the last MAC PDU in the MAC 
block is equal to the indicated or implicit PDU length then the MAC sets the "fill bit indication" to 0. In 
either case, the recipient discards the bits added following the end of the indicated or implicit length of 
the last MAC PDU. 

The procedure for fill bit addition is valid for both MS and BS. 

23.4.2.3 PDU association 

PDU association may be used when several small PDUs can be fitted into a single MAC block for transfer across the air 
interface. The PDUs are independent. And the BS may associate PDUs addressed to different MSs within one MAC 
block. However, the MS shall not associate PDUs sent using different addresses within one MAC block. 

NOTE 1: The MS's ISSI and its associated ASSI are equivalent for the purposes of PDU association by an MS (so 
the MS is not precluded from performing PDU association for PDUs sent using its ISSI and ASSI). 
Similarly, an event label and its corresponding address are equivalent for the purposes of PDU association 
by an MS. Also the MS is not precluded from performing PDU association of PDUs sent using a newly 
assigned ASSI with PDUs sent using the replaced ASSI or USSI. 

However, an MS is not permitted to associate PDUs sent using its SMI with PDUs sent using an SSI 
within a single MAC block; also an MS is not permitted to associate PDUs from multiple TSI families 
within a single MAC block. These restrictions may possibly be relaxed in future editions of the present 
document in the case of the final slot of an MS's requested reserved capacity. 

The MS is not permitted to associate PDUs sent using a GSSI with PDUs sent using another address. 

The association procedure is illustrated in figure 23.8. 



MAC Header 1 


TM-SDU 1 


MAC Header 2 


TM-SDU 2 




NULL PDU 



Figure 23.8: Association of several IVIAC PDUs in one IVIAC blocit 

Each PDU shall contain its own MAC header and each TMA-SAP PDU, except possibly the last in the MAC block, 
shall indicate the length of the PDU either explicitly or implicitly: 

• in the case of a MAC-U-BLCK or MAC-D-BLCK PDU, the length of the PDU is defined implicitly for each 
modulation type and bandwidth (see clauses 21.4.2.6 and 21.4.3.4); 



• 



for the other TMA-SAP PDUs, the length of the PDU is indicated explicitly, except possibly for the last PDU 
in the MAC block. 



The MAC header of the next PDU shall immediately follow the end of the current PDU. (Within a PDU, fill bits shall 
be inserted as required.) If there are no more PDUs to follow, a special message (the Null PDU) may be used if it fits 
within the remaining space in the MAC block. If there are unused bits, they shall follow the rules for fill bit addition. 

This procedure is valid for both MS and BS. 
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In order to associate, the MAC shall: 

a) prepare a PDU: 

for a MAC-U-BLCK or MAC-D-BLCK PDU, the MAC shall place the relevant MAC header in front of 
the TM-SDU; the length of the PDU is defined implicitly; 

for the other TMA-SAP PDUs, the MAC shall place the relevant MAC header in front of the TM-SDU, 
including the PDU length (except in the cases indicated below); in cases where the PDU length cannot be 
represented exactly by the defined values of the length indication, the MAC shall round up to the next 
higher valid value of the length indication (including fill bits to make up the difference between the 
actual PDU content and the indicated PDU length); 

for a TMB-S AP PDU, the size of the PDU is implicit from the MAC header; 

b) if the PDU does not completely fill the MAC block then: 

if the size of the remainder of the MAC block < appropriate Null PDU size (see below) then the MAC 
shall complete the MAC block such that the first bit after the user data shall be set to " 1 " and the 
following bits shall be set to "0"; or 

if the size of the remainder of the MAC block > appropriate Null PDU size (see below) then the MAC 
shall either: 

■ repeat step a) with another PDU; or 

■ use the Null PDU and complete the remainder (if any) with fill bits. 

For the downlink, the Null PDU size to be used for the comparison in b) shall be 16 bits. For the uplink, the comparison 
in b) shall be performed using the Null PDU size that corresponds to an address length of 24 bits. This is 36 bits in a 
subslot, or 37 bits in a full slot or on STCH. This rule shall apply even if the MS has been assigned an event label. 

Association shall not be performed if the remainder of the MAC block is less than the size of the appropriate Null PDU, 
even if the MAC has a PDU to send that is shorter than the Null PDU. 

NOTE 2: The "length indication" element in the MAC header refers to the size of the complete MAC PDU 

(rounded up to the next higher valid value of length indication), not to the length of the TM-SDU. The 
length of the TM-SDU is then known, since the TM-SDU follows immediately after the MAC header. 

NOTE 3: The definition of the "length indication" element uses two units Y and Z where, for length indication 
values up to division point D, the length of the MAC PDU is given in units of Y octets. For length 
indication values above division point D, the incremental unit of the length indication is Z octets (where 
Z > Y). In cases where Z > Y this definition allows a lower overhead for shorter PDUs. 

NOTE 4: Length indications 1 11 II2 (for MAC-ACCESS PDUs) and 1 1 1 IOI2 (for MAC-DATA and 

MAC -RESOURCE PDUs) define a specific length in bits - set to correspond to the normal size of an 
advanced link data segment on a QAM channel. If this specific length is not appropriate then the required 
value V of the "length indication" element is as follows: 

if BITS < 8 X Y X D then V = 1 H- ( (BITS - 1) DIV (8 x Y) ) 

if BITS > 8 X Y X D then V = 1 H- D H- ( (BITS - (8 x Y x D) - 1) DIV (8 x Z) ) 

where: 

BITS is the PDU size in bits; 

D = 14, Y = Yi and Z = Zi when sending a MAC-ACCESS PDU; 

D = 0, Y = Yi and Z = Zi when sending a MAC-END-HU PDU; 

D = 18, Y = Y2 and Z = Z2 when sending a MAC-DATA, MAC-RESOURCE or 
downlink MAC-END PDU; 

D = 6, Y = Y2 and Z = Z2 when sending an uplink MAC-END PDU; and 
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■ DIV represents integer division, rounded down. 

The values of Yj, Y2, Zi and Z2 depend on the modulation and the QAM coding rate and bandwidth with 
which the PDU is sent. They are given in clause 21.6. 

NOTE 5: There will be some cases when the PDU only just fits within the MAC block so that, after rounding up to 
the next higher valid value of length indication, the "length indication" element may indicate a value 
which exceeds the available capacity of the MAC block. Similarly the implicit length may indicate a 
value which exceeds the available capacity of the MAC block. 

NOTE 6: In the present document, the only TMB-SAP PDUs for which association may apply are: 

the ACCESS-DEFINE PDU; and 

the SYSINFO PDU when it is sent using 71/8-D8PSK modulation; and 

the SYSINFO-Q PDU. 

The following points apply for TMA-SAP PDUs other than MAC-U-BLCK and MAC-D-BLCK: 

• When a BS performs fragmentation, it shall send the first fragment and continuation fragments as the last PDU 
in a MAC block. Or, when an MS has further signalling to send, it shall include the reservation requirement in 
the MAC header of the last (non-Null) PDU in a MAC block. In both these cases, the PDU length cannot be 
indicated in the MAC header. Also, when an MS-MAC does not require to perform association within an 
uplink subslot, it should not include the "length indication" element in the MAC-ACCESS PDU except when it 
needs to send the Null PDU in a subslot. 

• In all three cases, the PDU shall be deemed to fill the remainder of the MAC block, and the length of the 
TM-SDU, or TM-SDU fragment, shall be indicated by use of the "fill bit indication" and any fill bits. 

For MAC-U-BLCK and MAC-D-BLCK, the length of the PDU is defined implicitly for each modulation type and 
bandwidth: 

• When the PDU is sent using 7i/4-DQPSK or 71/8-D8PSK modulation, the implicit length is equal to the size of 
the MAC block, so the MAC-U-BLCK or MAC-D-BLCK PDU is always the last PDU in the MAC block; the 
PDU size (before removal of fill bits) is equal to: 

the size of the MAC block if this is the only PDU in the MAC block; or 

the available capacity of the MAC block if this is not the first PDU in the MAC block. 

• When the PDU is sent using QAM modulation with modulation level higher than 4-QAM or for bandwidths of 
100 kHz or more, the implicit length is less than the size of the MAC block, so association may apply 
following the PDU. 

23.4.3 PDU decomposition for signalling messages 
23.4.3.1 Reconstruction (TMA-SAP only) 

This procedure is the opposite to fragmentation which is performed by the sender as described in clause 23.4.2.1. 

23.4.3.1 .1 Reconstruction of downlink TM-SDU 

The MS-MAC shall attempt to receive and decode the downlink slots appropriate to the relevant control channel (within 
the constraints of the energy economy or dual watch regime or the napping procedures, and the cell reselection 
procedures, and linearization and transmission requirements). 

On receipt of a MAC-D-BLCK PDU containing one of its valid event labels, the MS-MAC shall deliver the TM-SDU 
to the LLC using the TMA-UNITDATA indication primitive. Other actions may be performed relating to other 
elements in the MAC header. 
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On receipt of a MAC-RESOURCE PDU containing one of its valid addresses or event labels, the MS -MAC shall 
perform the following actions relating to the TM-SDU. Other actions may be performed relating to other elements in the 
MAC header. 

a) If the MAC-RESOURCE PDU contains "Length indication" ;^ 1 1 1 1 1 12, indicating no fragmentation, then the 
MS-MAC shall dehver the TM-SDU (if any) to the LLC using the TMA-UNITDATA indication primitive. 

b) If the MAC-RESOURCE PDU contains "Length indication" = 1111112, indicating the start of fragmentation, 
then the MS-MAC shall store the TM-SDU fragment. (The length of the first fragment is indicated only by the 
"fill bit indication" and any fill bits.) 

The MS-MAC shall then receive all the downlink slots on this control channel, looking for continuation 
fragments or for the end of the fragmented data i.e. MAC -FRAG or MAC-END PDU respectively. 

On receipt of a MAC -FRAG PDU, the MS-MAC shall append the TM-SDU fragment to the already received 
fragment(s). (The length of a continuation fragment is indicated only by the "fill bit indication" and any fill 
bits.) The MS-MAC shall then continue to receive the control channel, looking for further MAC -FRAG PDUs 
or for the MAC-END PDU. 

On receipt of a MAC -END PDU, the MS -MAC shall append the TM-SDU fragment to the already received 
fragment(s). (The length of the final fragment is indicated by the combination of the "Length indication", the 
"fill bit indication" and any fill bits.) The MS-MAC shall then dehver the reconstructed TM-SDU to the LLC 
using the TMA-UNITDATA indication primitive. 

NOTE: Occasionally the MAC -END PDU will contain no user data, in which case the already assembled 
fragments comprise the complete TM-SDU. On receipt of MAC-END, the MS-MAC delivers the 
TM-SDU to the LLC. 

The MS-MAC shall continue this process until it receives the MAC-END PDU, or until one of the following 
occurs: 

i) it receives any MAC-RESOURCE PDU on this control channel containing "Length indication" 
= IIIIII2 (for any address, not only one of its own addresses or event labels); 

ii) it fails to decode an SCH MAC block on this control channel (see below); 

iii) it has received N.203 consecutive slots on this control channel without receiving a fragment of its 
TM-SDU. 

In all three cases, the MS -MAC shall discard the partially reconstructed TM-SDU. In case i), if the 

MAC -RESOURCE PDU contains one of its own addresses or event labels, the MS-MAC shall then continue 

to process that new PDU. 

The MS shall provide adequate buffering to store a fragmented TM-SDU which may be up to N.202 bits in length. The 
MS-MAC does not dehver any part of the TM-SDU to the LLC until the complete TM-SDU has been received. 

The appropriate types of SCH MAC block in criterion ii) shall be: 

• an SCH/HD or SCH/F MAC block if the MS is on a 7i/4-DQPSK channel; 

• an SCH/HD, SCH/F, SCH-P8/HD or SCH-P8/F MAC block if the MS is on a D8QPSK channel; or 

• any SCH-Q/D MAC block if the MS is on a QAM channel. 

For the purposes of the reconstruction procedure, an MS on a QAM channel shall also regard it as failure to decode an 
SCH MAC block on this control channel if the MS does not attempt to decode the main part of the slot because it fails 
to decode the downlink QAM-SLOTINFO PDU or does not understand the value of the "slot format" element in the 
downlink QAM-SLOTINFO PDU or is not capable of processing slots with the indicated format. 

23.4.3.1 .2 Reconstruction of uplink TM-SDU 

On receipt of a MAC-U-BLCK PDU, the BS shall assume that the received TM-SDU is complete. 

On receipt of a MAC-ACCESS or MAC -DATA PDU, the BS shall perform the following actions relating to the 
TM-SDU. 
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If the received PDU does not indicate start of fragmentation then the BS shall assume that the received TM-SDU is 
complete. 

If the received PDU indicates start of fragmentation, and if the BS decides to grant capacity for the fragmented 
message, then the BS shall store the TM-SDU fragment. It shall also attempt to receive any subslot or slots granted to 
the MS for this address on this control channel (either granted already or granted in subsequent MAC-RESOURCE, 
MAC-END or MAC-D-BLCK PDUs), looking for further fragments of the TM-SDU. 

NOTE 1: The MS ISSI and its associated ASSI are equivalent for the purposes of usage of granted slots (so the MS 
will use any capacity granted on its ISSI for a fragmented message being sent with its ASSI, or vice 
versa). Similarly, an event label and its corresponding address are equivalent for the purposes of usage of 
granted slots. Also, a newly assigned ASSI is equivalent to the replaced ASSI or USSI for the purposes of 
usage of granted slots. 

a) If the MS requested a single subslot, and the BS grants a subslot for a final fragment, then the BS shall inspect 
the first PDU in that subslot. 

If the BS receives the MAC-END-HU PDU, it shall append the TM-SDU fragment to the first fragment, and 
shall assume that the received TM-SDU is complete. 

If the BS receives the MAC-ACCESS PDU, it shall discard the old fragment and shall continue to process the 
new PDU. 

If the BS fails to decode the uplink subslot, it shall discard the old fragment. 

b) If the BS grants full slots to the MS, then it shall attempt to receive those granted slots, looking for the 
MAC-FRAG or MAC-END PDU. 

On receipt of a MAC -FRAG PDU, the BS shall append the TM-SDU fragment to the already received 
fragment(s). It shall then continue to attempt to receive the granted slots, looking for further MAC -FRAG 
PDUs or for the MAC-END PDU. 

On receipt of a MAC-END PDU, the BS shall append the TM-SDU fragment to the already received 
fragment(s), and shall assume that the received TM-SDU is complete. 

NOTE 2: Occasionally the MAC -END PDU will contain no user data, in which case the already assembled 
fragments comprise the complete TM-SDU. 

The BS may continue this process (granting more slots if appropriate) until it receives the MAC -END PDU, or 
until one of the following occurs: 

i) it receives a MAC-DATA or MAC-U-BLCK PDU in one of the granted slots; 

ii) it fails to decode a MAC block in one of the granted slots; 

iii) it has not granted slots to the MS nor sent the instruction to "Wait for another Slot Grant", and a time 
T.202 has elapsed since the last slot granted to the MS on this control channel (see clause 23.4.2.1.2). 

In all three cases, the BS shall discard the partially reconstructed TM-SDU. In case i), the BS shall continue to 
process the new PDU. In case ii), the BS shall discard any MAC-FRAG or MAC-END PDUs received in any 
further slots granted to this MS for this address (until receipt of the next MAC-ACCESS, MAC-DATA or 
MAC-U-BLCK PDU fi-om the MS). 

If, at any time, the BS receives a MAC -FRAG, MAC-END or MAC-END-HU PDU in a granted slot or subslot, without 
a corresponding start of fragmentation from this MS (on this control channel), the BS shall discard the PDU. 

NOTE 3: After receiving a fragmented TM-SDU containing a BL-DATA or BL-ADATA message, the BS may 
choose to send the LLC acknowledgement more than once (for reliability). 
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23.4.3.1.3 Reconstruction in minimum mode 

a) Downlink TM-SDU 

During minimum mode, the MS-MAC shall follow the defined minimum mode rules for receiving and 
decoding the downlink for signalling messages in frames 1 to 17 and in frame 18. 

The normal procedure for reconstruction of a downlink TM-SDU, described in clause 23.4.3.1.1, generally 
applies except that, after the MS-MAC receives a MAC-RESOURCE PDU addressed to itself and containing a 
start of fragmentation, the procedure b) of clause 23.4.3.1.1 for looking for continuation fragments 
(MAC-FRAG) or for the end of the fragmented data (MAC-END) shall apply only to the MS's designated 
minimum mode frame 18 slot. 

Also, the normal criteria ii) and iii) of clause 23.4.3.1.1 for discarding a partially reconstructed TM-SDU shall 
be replaced by the following criteria ii) and iii): 

ii) it fails to decode an SCH MAC block in its designated minimum mode frame 18 slot; 

iii) it has received its designated minimum mode slot in N.203 consecutive frame 18s without receiving a 
fragment of its TM-SDU. 

On leaving minimum mode, the MS-MAC shall return to the normal method of reconstruction (i.e. looking for 
fragments in all downlink slots on the MCCH). 

NOTE 1: The above minimum mode procedure applies only to those MSs that are in common control mode and 
receiving the MCCH. It does not apply to MSs on an assigned channel. 

NOTE 2: While receiving a fragmented message during minimum mode, the MS-MAC is still required to receive 
slot 1 of frames 2 to 17, e.g. it may be sent a non-fragmented message. As defined in criterion i) of 
clause 23.4.3.1.1, the MS discards the partially reconstructed message if it receives any 
MAC -RESOURCE PDU on this channel containing "Length indication" = 1111112 •^i-^- ^^^^^ °f 
fragmentation). 

NOTE 3: The reconstruction procedure defined above applies only when the MAC -RESOURCE PDU was sent on 
SCH/F or SCH/HD (in slot 1 of frames 2 to 17 if the downlink is in FACCH or assigned SCCH, or in the 
MS's minimum mode frame 18 slot). If the MAC-RESOURCE PDU was sent on STCH then the 
reconstruction procedure defined in clause 23.4.3.1.7 applies. 

b) Uplink TM-SDU 

The normal procedure for reconstruction of an uplink TM-SDU, described in clause 23.4.3.1.2, applies during 
minimum mode. 

23.4.3.1 .4 Reconstruction on time-shared control channel 

a) Downlink TM-SDU 

On a time-shared MCCH, the MS-MAC shall follow the defined rules for receiving and decoding the 
downlink for signalling messages. 

The normal procedure for reconstruction of a downlink TM-SDU, described in clause 23.4.3.1.1, generally 
applies except that, after the MS-MAC receives a MAC-RESOURCE PDU addressed to itself and containing a 
start of fragmentation, the procedure b) of clause 23.4.3.1.1 for looking for continuation fragments 
(MAC-FRAG) or for the end of the fragmented data (MAC-END) shall apply only to slot 1 of the reserved 
frames for this BS, not to the common frames. 

Also, the normal criteria ii) and iii) of clause 23.4.3.1.1 for discarding a partially reconstructed TM-SDU shall 
be replaced by the following criteria ii) and iii): 

ii) it fails to decode an SCH MAC block in slot 1 of one of the reserved frames for this BS; 

iii) it has received slot 1 of N.203 consecutive reserved frames for this BS without receiving a fragment of 
its TM-SDU. 
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NOTE: While receiving a fragmented message, the MS -MAC is still required to attempt to receive and decode 
slot 1 of the common frames, e.g. it may be sent a non-fragmented message. 

For a time-shared common SCCH, "slot 1" in the above shall be replaced by the appropriate slot number on 
the main carrier. 

b) Uplink TM-SDU 

The normal procedure for reconstruction of an uplink TM-SDU applies. 

23.4.3.1 .5 Reconstruction on assigned channel if downlink is in SACCH 

a) Downlink TM-SDU 

In frames 1 to 17, reconstruction of downlink STCH may apply (see clause 23.4.3.1.7). 

The normal procedure for reconstruction of a downlink TM-SDU, described in clause 23.4.3.1.1, generally 
applies for a message sent on the SACCH in frame 18 with the following differences: 

1) If an MS that is transmitting traffic on the uplink receives a MAC -RESOURCE PDU in frame 18 of the 
assigned channel, individually addressed to itself and containing a start of fragmentation, the 
procedure b) of clause 23.4.3.1.1 for looking for continuation fragments (MAC-FRAG) or for the end of 
the fragmented data (MAC-END) shall apply only to the highest numbered downlink slot of the assigned 
channel in those frame 18s indicated by the assigned monitoring pattern(s). 

Also, the normal criteria ii) and iii) of clause 23.4.3.1.1 for discarding a partially reconstructed TM-SDU 
shall be replaced by the following criteria ii) and iii): 

ii) it fails to decode an SCH MAC block in the highest numbered downlink slot of the assigned 
channel in a frame 18 indicated by the assigned monitoring pattern(s); 

iii) it has received the highest numbered downlink slot of the assigned channel in N.203 consecutive 
frame 18s indicated by the assigned monitoring pattern(s) without receiving a fragment of its 
TM-SDU. 

If the MS switches out of traffic transmit mode, it reverts to procedure 2). Or, if the downlink leaves 
SACCH, the MS reverts to the procedure for reconstruction when the downlink is in FACCH. 

NOTE 1 : For a single-slot channel, the highest numbered downlink slot of the assigned channel is implicitly the one 
slot of the assigned channel, as defined by element "timeslot assigned". 

NOTE 2: For a simplex call, the transmitting MS recognizes that the downlink is in SACCH by using the 

ACCESS-ASSIGN PDU as defined in clause 23.5.6.3. For a duplex call, the duplex traffic transmit 
permission included traffic receive permission and thus indicated that the downlink is in SACCH. 

NOTE 3: The reconstruction procedure defined above applies only for a message individually addressed to an MS 
that is transmitting traffic on the uplink. If the MS receives the start of a group addressed fragmented 
message then it should either discard the TM-SDU fragment or continue the reconstruction using 
procedure 2). 

2) If an MS that is not transmitting traffic on the uplink receives a MAC -RESOURCE PDU in frame 18 of 
the assigned channel, addressed to itself and containing a start of fragmentation, the procedure b) of 
clause 23.4.3.1.1 for looking for continuation fragments (MAC-FRAG) or for the end of the fragmented 
data (MAC-END) shall apply only to the lowest numbered downlink slot of the assigned channel in 
frame 18. 

Also, the normal criteria ii) and iii) of clause 23.4.3.1.1 for discarding a partially reconstructed TM-SDU 
shall be replaced by the following criteria ii) and iii): 

ii) it fails to decode an SCH MAC block in the lowest numbered downlink slot of the assigned channel 
in frame 18; 

iii) it has received the lowest numbered downlink slot of the assigned channel in N.203 consecutive 
frame 18s without receiving a fragment of its TM-SDU. 
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If the MS switches into traffic transmit mode, it reverts to procedure 1). Or, if the downlink leaves 
SACCH, the MS reverts to the procedure for reconstruction when the downlink is in FACCH. 

NOTE 4: Procedure 2) applies both to MSs receiving traffic on the channel in a simplex call and to any MSs not in 
traffic mode. The use of only the lowest numbered downlink slot in frame 18 for MAC -FRAG and 
MAC -END means that an MS receiving in traffic mode on a multi-slot channel is not required to modify 
its reception pattern during the reconstruction. 

For a single-slot channel, the lowest numbered downlink slot of the assigned channel is implicitly the one 
slot of the assigned channel, as defined by element "timeslot assigned". 

NOTE 5: If the MS is receiving traffic on the channel then the traffic receive permission informed it that the 
downlink is in SACCH. If the MS is not in traffic mode on the channel then it recognizes that the 
downlink is in SACCH (i.e. carrying traffic for other MSs) by using the ACCESS-ASSIGN PDU as 
defined in clause 23.5.6.3. 

NOTE 6: In procedure 1), while receiving a fragmented message on SACCH, the MS-MAC also receives in frames 
1 to 17 when appropriate. In procedure 2), while receiving a fragmented message on SACCH, the 
MS-MAC also receives in frames 1 to 17. In either case, the MS may be sent a non-fragmented message 
on STCH. And, as defined in criterion i) of clause 23.4.3.1.1, the MS discards the partially reconstructed 
message if it receives any MAC-RESOURCE PDU on this assigned channel containing "Length 
indication" = IIIIII2 (i.e. start of fragmentation). 

b) Uplink TM-SDU 

If the uplink is in traffic then, in frames 1 to 17, reconstruction of uplink STCH may apply (see 
clause 23.4.3.1.7). 

The normal procedure for reconstruction of an uplink TM-SDU, described in clause 23.4.3.1.2, applies on 
uplink SACCH or FACCH. 

23.4.3.1 .6 Reconstruction on assigned channel if downlink is in FACCH or assigned SCCH 

a) Downlink TM-SDU 

The normal procedure for reconstruction of a downlink TM-SDU, described in clause 23.4.3.1.1, generally 
applies when an assigned channel is not in downlink traffic with the following differences for an MS that is 
transmitting traffic on the uplink: 

If an MS that is transmitting traffic on the uplink receives a MAC -RESOURCE PDU individually 
addressed to itself and containing a start of fragmentation, the procedure b) of clause 23.4.3.1.1 for 
looking for continuation fragments (MAC-FRAG) or for the end of the fragmented data (MAC-END) 
shall apply only to those slots where the MS is required to look for further fragments (as defined below). 

Also, the normal criteria ii) and iii) of clause 23.4.3.1.1 for discarding a partially reconstructed TM-SDU 
shall be replaced by the following criteria ii) and iii): 

ii) it fails to decode an SCH MAC block in one of the slots where it is required to look for further 
fragments; 

iii) it has received N.203 consecutive slots where it is required to look for further fragments without 
receiving a fragment of its TM-SDU. 

For a single-slot channel, the "slots where the MS is required to look for further fragments" (as used 
above) shall comprise the downlink slot, as defined by element "timeslot assigned", in those frames 
indicated by the assigned monitoring pattern(s). 

For a frequency half duplex MS transmitting traffic on a multi-slot channel, the "slots where the MS is 
required to look for further fragments" (as used above) shall comprise: 

■ in frames 1 to 17: no slots; and 

■ in frame 18: the highest numbered downlink slot of the assigned channel, in those frame 18s 
indicated by the assigned monitoring pattern(s). 
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For a frequency frill duplex MS transmitting traffic on a multi-slot channel, the "slots where the MS is 
required to look for further fragments" (as used above) shall comprise: 

■ in frames 1 to 17: all slots of the downlink assigned channel, as defined by element "timeslot 
assigned", in those frames indicated by the assigned monitoring pattern(s); and 

■ in frame 18: the highest numbered downlink slot of the assigned channel, in those frame 18s 
indicated by the assigned monitoring pattern(s). 

NOTE 1: The reconstruction procedure defined above for a frequency half duplex MS transmitting traffic on a 
multi-slot channel applies even if the MS has fast switching capability. 

NOTE 2: The reconstruction procedure defined above applies only for a message individually addressed to an MS 
that is transmitting traffic on the uplink. If the MS receives the start of a group addressed fragmented 
message then it should either discard the TM-SDU fragment or continue the reconstruction using the 
normal procedure defined in clause 23.4.3.1.1 (i.e. overriding the monitoring pattern information and 
assuming that continuation and final fragments may be transmitted on any downlink slot appropriate to 
the assigned channel). 

NOTE 3: The normal reconstruction procedure defined in clause 23.4.3.1.1 applies for MSs that are not currently 
transmitting traffic on the uplink. So continuation and final fragments may be transmitted on any 
downlink slot appropriate to the assigned channel. 

b) Uplink TM-SDU 

If the uplink is in traffic then, in frames 1 to 17, reconstruction of uplink STCH may apply (see 
clause 23.4.3.1.7). 

The normal procedure for reconstruction of an uplink TM-SDU, described in clause 23.4.3.1.2, applies on 
uplink SACCH or FACCH. 

23.4.3.1 .7 Reconstruction on stealing channel 

On the stealing channel STCH, fragmentation is only permitted within one timeslot. The procedure for reception of 
STCH (including reconstruction within the two half slots of one stolen timeslot) is described in clause 23.8.4. 

23.4.3.2 Fill bit deletion 

On receipt of a TMA-SAP PDU, the MAC shall check whether fill bits are present ("fill bit indication" set to 1 in the 
PDU header). If fill bits are present, the MAC shall: 

• inspect the last bit of the PDU; 

• if the last bit is " 1 ", remove this bit; then the rest of the data is the true PDU content; 

• if the last bit is "0", remove this bit and all preceding zeros until a bit "1" is found; remove this bit "1"; then the 
rest of the data is the true PDU content. 

NOTE: The maximum number of fill bits to remove is normally (8Zi - 1) bits for a PDU in a subslot, or 

(8Z2 - 1) bits for a PDU in a slot, if a specific length indication is given in the MAC header. (The values 
of Zi and Z2 are given in clause 21.6.) It may be a larger number in the case of an implicit length 
indication (i.e. for MAC-U-BLCK or MAC-D-BLCK) or, for the other TMA-SAP PDUs, if there is no 
length indication or if the length indication is set to 1 1 1 1 12 or 1 1 1 IOI2 or 1 1 1 1 IO2. 

Fill bits used for completing a MAC block after the Null PDU, or if there is not enough space for a Null PDU, shall be 
discarded. 

The procedure for fill bit deletion is valid for both MS and BS. 
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23.4.3.3 PDU dissociation 



PDU dissociation shall be used when several small PDUs have been fitted into a single MAC block by the association 
procedure. 

Each TMA-S AP PDU (except possibly the last in the MAC block) indicates the length of the PDU - either explicitly or, 
in the case of a MAC-U-BLCK or MAC-D-BLCK PDU, implicidy. The MAC header of the next PDU immediately 
follows the end of the current PDU as indicated by the "length indication" element or the implicit length. So separation 
of PDUs from each other relies on the "length indication" contained in the first MAC header or the implicit length of the 
first MAC PDU, then the "length indication" contained in the second MAC header or the implicit length of the second 
MAC PDU, and so on. The Null PDU indicates that there is no more useful data in this MAC block; after receipt of the 
Null PDU, the MAC shall not look for further information in the block. If the remaining size in the MAC block is less 
than the length of the Null PDU, the MAC shall discard the remaining bits. 

This procedure is valid for both MS and BS. 

In order to dissociate, the MAC shall: 

• decode the first MAC header and determine the length of the PDU: 

for a MAC-U-BLCK or MAC-D-BLCK PDU, the length of the PDU is defined imphcitly; 

for the other TMA-SAP PDUs, the MAC shall extract the PDU length indication (if included); if there is 
no length indication, the PDU size shall be deemed to be the remainder of the MAC block; 

for a TMB-SAP PDU, the exact size of the PDU is implicit from the MAC header; 

• remove any fill bits contained in the PDU, if indicated by the "fill bit indication"; 

• repeat the above steps until a Null PDU is found or the remaining space in the block is less than the size of the 
appropriate Null PDU (see note). 

Each separate PDU shall then be further processed by the MAC. 

There will be some cases when the "length indication" or implicit length will indicate a value which exceeds the 
available capacity of the MAC block. The recipient MAC shall regard the length of the PDU as either the available 
capacity of the MAC block or the indicated or implicit length, whichever is the lesser. In either case, fill bits shall be 
removed if the "fill bit indication" is set to I. 

NOTE: The size of the appropriate Null PDU (as used above) is 16 bits for the downlink, 36 bits for an uplink 
subslot, or 37 bits for an uplink full slot or uplink STCH. 

23.4.3.4 PDU error detection 

The purpose of the CRC added to a MAC block by the lower MAC is to enable the MAC at the receiving side of the air 
interface to detect whether errors have been introduced into the message during transmission. Therefore, the receiving 
lower MAC shall extract the decoded CRC and shall calculate a CRC on the remainder of the data as in the transmitting 
case. The two CRCs shall be compared. If they are not identical, the CRC fail parameter in the TMV-UNITDATA 
indication primitive shall inform the receiving upper MAC that an error has occurred. 

Upon reception of a MAC block as indicated with the CRC fail parameter in the TMV-UNITDATA indication 
primitive, the upper MAC shall discard the incoming data. However, the upper MAC may use the CRC fail information 
to update its statistics on error measurement. 

Upon reception of a MAC block as indicated with the CRC pass parameter in the TMV-UNITDATA indication 
primitive, the upper MAC shall further check that the incoming PDU or PDUs are valid by inspecting the MAC 
headers. 

The lower MAC also performs error detection on the AACH and AACH-Q MAC blocks. 

Upon reception of an AACH or AACH-Q MAC block as indicated with the CRC fail parameter in the 
TMV-UNITDATA indication primitive, the upper MAC shall discard the data in that AACH or AACH-Q MAC block. 
However, the upper MAC uses the AACH or AACH-Q failure information to update its RDC, RDC-NC or RDC-Q 

statistics; see clause 23.7.3.1.1. 
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Upon reception of an AACH or AACH-Q MAC block as indicated with the CRC pass parameter in the 
TMV-UNITDATA indication primitive, the upper MAC shall process the data in that AACH or AACH-Q MAC block. 
The upper MAC also uses the AACH or AACH-Q success information to update its RDC, RDC-NC or RDC-Q 
statistics; see clause 23.7.3.1.1. 

23.4.4 Power control 

23.4.4.1 Overall process 

Adaptive RF power control shall be used by the MS. It allows the system to minimize the transmit power required by 
the MS whilst maintaining the quality of the radio uplink. By minimizing the transmit power levels, interference to 
co-channel and adjacent channel users is reduced and MS power consumption could be reduced. 

Two methods of adaptive RF power control may be used. The first method, known as open loop power control, shall be 
implemented in the MS. Using this method, the MS shall adjust its transmit power based on the power level or 
equivalent signal quality being received by the MS on the downlink from the BS. The second method, known as closed 
loop power control, shall be supported by the MS and may be implemented in the BS. Using this method, the MS shall 
adjust its transmit power as instructed by the BS. The BS shall calculate the optimal MS transmit power, for example 
based upon the power level being received on the uplink from that MS. The exact method of measurement and 
calculation in the BS are outside of the scope of the present document. 

These methods are described in more detail in the following clauses. Adaptive RF power control shall not be used to 
control the BS transmit power. 

23.4.4.2 MS open loop power control 

23.4.4.2.1 Obtaining values of MS_TXPWR_MAX_CELL and ACCESS_PARAMETER 

The MS open loop power control procedure uses two parameters: MS_TXPWR_MAX_CELL and 
ACCESS_PARAMETER (see clause 23.4.4.2.2). These parameters are broadcast by the BS: 

• in the SYSINFO PDU broadcast by the BS on the BNCH on a 7i/4-DQPSK or D8PSK channel; 

• in the SYSINFO-Q PDU broadcast by the BS on the BNCH-Q on a QAM channel. 

The values of these parameters may vary according to the modulation mode and bandwidth of the channel (and 
according to whether the channel is conforming, non-conforming concentric or sectored): 

• when the MS first acquires a main carrier or receives a channel allocation for a new cell or is sent to a new 
7I/4-DQPSK channel within the cell, it shall make the assumptions specified in clause 23.6.6.1 about the values 
of these parameters until updated by receiving SYSINFO PDUs on that channel; 

• when the MS is sent to a D8PSK channel, it shall make the assumptions specified in clause 23.6.6.2 about the 
values of these parameters until updated by receiving SYSINFO PDUs on that channel; 

• when the MS is sent to a QAM channel, it shall make the assumptions specified in clause 23.6.6.3 about the 
values of these parameters until updated by receiving SYSINFO-Q PDUs on that channel. 

23.4.4.2.2 MS open loop power control procedure 

Open loop power control shall be implemented in the MS. The power level shall be controlled for all transmitted bursts 
except random access messages for which power level control may be based only on the MS_TXPVv'R_MAX_CELL 
parameter (and the bandwidth when on a QAM channel). 

An MS, when camped on a cell, shall obtain the appropriate values of the MS_TXPWR_MAX_CELL and 
ACCESS_PARAMETER parameters for the current channel as specified in clause 23.6.6. 
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For any reserved access or traffic transmissions, the MS shall use the transmit power level supported by the MS that is 
the closest to Pf^^, where Pj^^ is defined by: 

P^^ = MIN ( MS_TXPWR_MAX_CELL, ACCESS_PARAMETER - RSSI ) (23. 1) 

where: MS_TXPWR_MAX_CELL = Maximum MS transmit power allowed on that channel; 

ACCESS_PARAMETER = Parameter for transmit power calculation on that channel; 

RSSI = Averaged signal level received by the MS or an equivalent signal quality measurement. 

All values are expressed in dBm. The nominal MS power control level shall not exceed the maximum MS transmit 
power indicated in the MS_TXPWR_MAX_CELL parameter for that channel. 

NOTE: ACCESS_PARAMETER is based on BS power and configuration and on the required mean power level 
received at the BS. On a D8PSK channel, it is expected that the BS will set the ACCESS_PARAMETER 
so that the MS power is not reduced until the MS could use 71/8-D8PSK modulation for some data 
categories. On a QAM channel, it is expected that the BS will set the ACCESS_PARAMETER so that the 
MS power is not reduced until the MS could use the highest permitted uplink bit rate (with the possible 
exception of coding rate r = 1) for some data categories. 

The MS, while receiving traffic or signalling, shall update P^^ for the current channel at least every 30 s and, in case of 
modification, may linearize on a subslot provided for common linearization (CLCH or CLCH-Q). 

The MS, while transmitting, shall update Pj^^ at least every 3 s based upon its RSSI measurements. The MS shall adjust 
its transmit power to the level supported by the MS that is the closest to ^y^^, at the latest, immediately following the 
next common linearization opportunity on that channel. 

In the case of a random access transmission: 

• when on a 25 kHz channel, the MS may increase its nominal transmit power to a level supported by the MS 
that does not exceed the MS_TXPWR_MAX_CELL parameter for this channel in order to increase the 
probability of the random access transmission reaching the BS without being corrupted; 

• when on a QAM channel with bandwidth greater than 25 kHz, the nominal MS transmit power for a random 
access transmission shall not exceed MS_TXPWR_MAX_CELL - 10 logio ( B / 25 ), where: 

MS_TXPWR_MAX_CELL = Maximum MS transmit power allowed on that channel; 

B = bandwidth of the QAM channel in kHz. 

23.4.4.3 MS closed loop power control 

Closed loop power control may be employed by a BS in order to control the power of an MS transmitting in circuit 
mode on a traffic channel. 

NOTE 1 : Closed loop power control therefore applies only on a 7i/4-DQPSK channel. 

The MS shall obey power control messages from the BS while the MS-MAC is transmitting in U-plane mode. Such 
power control instructions shall be obeyed only for the duration of that U-plane transmission after which the MS shall 
revert to open loop power control for subsequent transmissions. 

When the MS -MAC switches from C-plane to U-plane transmission mode, or at any time during the U-plane 
transmission, the BS may control the MS transmit power by sending a MAC-RESOURCE PDU which includes the 
optional power control element, to instruct the MS to increase or decrease its transmit power by the appropriate number 
of steps (or remain at its current power level, see note 2). A step is equal to 5 dB except that, if an MS with a power 
class "L" is currently transmitting at its maximum transmit power, then the first step is 2,5 dB; see clause 6.4.1.2. 

NOTE 2: The step size is always 5 dB for an MS that is not using a power class "L". It is also 5 dB for an MS with 
a power class "L" for steps other than the first step down from its maximum transmit power. The 2,5 dB 
first step for an MS with a power class "L" enables the MS to step down onto one of the nominal MS 
power control levels defined in clause 6.4.1.2. 
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The MS shall obey these power control instructions. If the MS is instructed to increase its power above the maximum 
transmit power of that MS then it shall set its power to the maximum transmit power. Similarly, if it is instructed by the 
BS to set its power below the minimum power control level of 15 dBm, then it shall set its power to 15 dBm. The MS 
shall adjust its power after receiving a power control message, at the latest, immediately following the next common 
linearization opportunity. This power level shall take precedence over open loop power control and shall be used for all 
subsequent traffic and signalling transmissions, including any transmissions in frame 18, for the duration of the U-plane 
transmission until one of the following events occurs: 

a) the MS ends its transmission and switches out of U-plane mode; or 

b) the MS receives a MAC-RESOURCE PDU with the power control element set to "Revert to open loop power 
control". 

Then the MS shall revert to using the rules defined for open loop power control as defined in clause 23.4.4.2. During 
closed loop power control operation, the MS shall continue to maintain its RSSI estimate for the downlink so that P^^ 

is always up to date. 

NOTE 3: A power control message may instruct the MS to increase or decrease its transmit power. Alternatively, a 
power control element set to "No change in power" (value OOOO2) instructs the MS to remain at its current 

power level, with that power level taking precedence over open loop power control until event a) or b) 
occurs. 

23.4.5 MS linearization 

23.4.5.1 MS linearization on tt/4-DQPSK or D8PSK channel 

The ACCESS-ASSIGN PDU on the AACH shall indicate those uplink subslots that are available for common use for 
linearization. The MS may linearize its transmitter using any subslot that is indicated as a "CLCH(-Q) subslot", without 
regard to the access code or common/assigned designation, and even on another physical channel. 

NOTE 1: If the ACCESS-ASSIGN PDU contains only one access field, and that access field indicates 

"CLCH(-Q) subslot", the MS assumes that subslot 1 may be used for linearization and that subslot 2 is 
reserved; see clause 23.5.1.4.2. 

In addition, during frame 18, the MS may linearize on the first subslot of the uplink slot defined by (in accordance with 
clause 9): 

CLCH mapped if: 

FN=ld. and (MN + TN) mod 4 = 3 (23.2) 

This provides a linearization opportunity at least every four multiframe periods on each of the four physical channels of 
a carrier. The MS may linearize during these subslots without checking the ACCESS-ASSIGN PDU contents but the 
BS should set the ACCESS-ASSIGN PDU appropriately to indicate a CLCH opportunity. 

If the BS is using discontinuous operation then the usage of this mapping is restricted as follows: 

• if the BS is using carrier sharing then the MS may linearize using this mapping without checking the 
ACCESS-ASSIGN PDU contents only on an assigned channel or on a common control channel that it is 
receiving; 

• if the BS is using MCCH sharing then the MS may linearize using this mapping without checking the 
ACCESS-ASSIGN PDU contents only on an assigned channel, or on a common control channel that it is 
receiving but restricted to those frame 18s that are reserved frames for this BS; 

• if the BS is using traffic carrier sharing then the MS may linearize using this mapping without checking the 
ACCESS-ASSIGN PDU contents only on the main carrier or on an assigned channel. 

The MS shall keep adequately linearized, so that it is ready at any time to send a message on the current uplink RF 
carrier (for example, a response to a BS paging message) without first needing to use a CLCH subslot. This rule shall 
apply even while the MS is in energy economy mode. 
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However, an exception is in the case of a dual watching MS which sometimes may not be able to maintain adequate 
V+D linearization during a Direct Mode call (see EN 300 396-3 [22], clause 8.4.7.10). Then the MS may, if necessary, 
use the first subslot of an individually addressed slot grant for linearization. If it does this then it shall maintain adequate 
V+D linearization on that carrier for at least the next 4 multiframe periods in order to be able to send a message by 
reserved access if required. 

NOTE 2: If the dual watching MS uses the first subslot of an individually addressed slot grant for linearization 
then, for a single-slot grant, it should not transmit in the second subslot of that slot; for a grant of more 
than one slot, it should not transmit in the second subslot of the first granted slot but then should send a 
V+D message in at least the second granted slot. 

23.4.5.2 MS linearization on QAM assigned channel 

The ACCESS-ASSIGN PDU on the AACH-Q shall indicate those uplink subslots that are available for common use for 
linearization. The MS may linearize its transmitter using any subslot that is indicated as a "CLCH(-Q) subslot", without 
regard to the access code or common/assigned designation, and even on another QAM physical channel. 

NOTE 1: If the ACCESS-ASSIGN PDU contains one access field, and that access field indicates 

"CLCH(-Q) subslot", the MS assumes that subslot 1 may be used for linearization and that subslot 2 is 
reserved; see clause 23.5.1.4.2. 

If the ACCESS-ASSIGN PDU is not present within the AACH-Q, the MS shall regard the corresponding uplink 
subslots as not available for common use for linearization. 

In addition, during frame 18, the MS may linearize on the first subslot of the uplink slot defined by (in accordance with 
clause 9): 

CLCH-Q mapped if: 

FN =18 and (MN + TN) mod 4 = 3 and TN is the lowest numbered timeslot of the allocated channel (23.3) 

This provides a linearization opportunity at least every four multiframe periods on the QAM assigned channel. The MS 
may linearize during these subslots without checking the ACCESS-ASSIGN PDU presence and contents but the BS 
should set the ACCESS-ASSIGN PDU appropriately to indicate a CLCH-Q opportunity. 

The MS shall keep adequately linearized, so that it is ready at any time to send a message on the uplink QAM channel 
without first needing to use a CLCH-Q subslot. This rule shall apply even when the MS is in napping mode. 

However, if necessary, the MS may occasionally use a reserved slot or subslot for linearization purposes provided that: 

• the slot or subslot has been granted to the MS by an individually addressed slot grant; and 

• the MS's emission for linearization purposes conforms to the spectrum mask defined in clause 6.4.9.2.1 for 
emission during the useful part of the burst. 

NOTE 2: For example, the MS may occasionally use this form of linearization in a reserved slot or subslot if it has 
been granted a large number of reserved slots on a multi-slot channel and is not able to maintain adequate 
linearization between the mapped CLCH-Q opportunities. 

23.4.6 BS synchronization 

When an MS moves from one carrier to another within a cell, it shall assume that the old frame and slot synchronization 
apply also on the new carrier. For example, at call set-up, it may immediately linearize and use granted slots or subslots 
using the timing of the old carrier. 

Therefore, the BS shall synchronize the slot, frame and multiframe timing on all its carriers within a cell. 

NOTE: This applies for all carriers within the cell. Thus the slot, frame and multiframe timing on both phase 

modulation carriers and any QAM carriers within the cell needs to be synchronized with the slot, frame 
and multiframe timing on the main carrier. See clause 7 for details of the synchronization of phase 
modulation carriers and QAM carriers. 
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23.4.7 Data priority 



Clauses 23.4.7.1, 23.4.7.2, 23.4.7.3, 23.4.7.4, 23.4.7.5 and 23.4.7.6 shall be applicable only to MSs and BSs which 
support data priority. 

23.4.7.1 General 

Data priority enables the MS to indicate a priority for obtaining reserved slots when it is sending packet data. For 
example, this permits the BS to grant slots to an MS with high data-priority PDUs to send ahead of other MSs with 
lower data-priority PDUs to send on the same channel. 

NOTE 1: Data priority is distinct from PDU priority. PDU priority affects the MS's queue re-ordering in the LLC 
and the MS's random access procedure. Data priority principally affects the BS's criteria for slot granting 
on a shared packet data channel, but is also used for queue re-ordering in the LLC. 

The SNDCP in an MS that uses data priority either regards the "MS default data priority" as being the "network default 
data priority" indicated by the SwMI or may negotiate a specific MS default data priority with the SwMI (see 
clause 28.3.5.5). In either case, the MS default data priority is a data priority which the BS applies by default to all 
reservation requirements indicated by that MS on a packet data channel unless temporarily overridden by a short-term 
data priority requested by the MS -MAC. The higher layers inform the MS -MAC about the current MS default data 
priority using the TMC-CONFIGURE request primitive. 

NOTE 2: The MS default data priority in the TMC-CONFIGURE request primitive may be set to one of the eight 
defined values of data priority (0 to 7) or may be set to "not applicable". The value "not applicable" 
applies if the SNDCP is not aware of the network default data priority and has not negotiated a specific 
MS default data priority (or if the current BS does not support data priority); it applies also when the 
SNDCP is not in the READY state. 

Also, when the SNDCP sends each packet data PDU, it includes the data priority for that PDU within the primitive 
issued to the lower layers. The LLC collates the information on the data priorities for the data in its queue and issues it 
to the MS -MAC in the DATA-IN-BUFFER signal, indicating: 

• the maximum value of the data priority for the data in the LLC queue for the specified address and endpoint 
identifier (set either to one of the eight defined values of data priority (0 to 7) or to value "undefined" if there 
is only data of undefined data priority in the LLC queue); and 

• if the endpoint identifier corresponds to a 7i/4-DQPSK channel: the subdivision of that data into data priorities; 

• if the endpoint identifier corresponds to a D8PSK or QAM channel: the subdivision of that data into data 
categories and data priorities. 

NOTE 3: The LLC also indicates (using the DATA-IN-BUFFER signal) whether or not it currently expects that the 
next PDU to be sent with the specified address and endpoint identifier will contain packet data. 

The MS-MAC sends an L2-DATA-PRI0RITY message when it wishes to indicate a short-term variation on that 
channel which temporarily overrides the default data priority. (The MS-MAC does not send the L2-DATA-PRIORITY 
message until the LLC wishes to send a PDU whose data priority differs from the MS default data priority.) 

The L2-DATA-PRIORITY message is a layer 2 signalling message, so the MS -MAC sends it using the data transfer 
service provided by the LLC at the TLE-SAP; see clause 23.1.4. 

23.4.7.2 Content of L2-DATA-PRI0RITY message 
23.4.7.2.1 Formats of L2-DATA-PRI0RITY message 

The MAC sends an L2-DATA-PRIORITY message when it wishes to indicate a short-term variation to the default data 
priority (see clause 23.4.7.4 for criteria for sending the L2-DATA-PRI0RITY message). The L2-DATA-PRI0RITY 
message applies to the address with which it is sent and the channel on which it is sent. It may contain either: 

1) a single short-term data priority (the "residual data priority"); or 
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2) up to 7 data priority blocks each containing: 

a data priority (the "temporary data priority"); and 

the expected number of slots needed to send the currently queued data at that data priority for this 
address and channel (as indicated in the DATA-IN-BUFFER signal from the LLC), 

followed by the "residual data priority", which applies to slots following those included in the data priority 
block(s). 

See clause 2L2.4.1 for the description of the L2-DATA-PRIORITY PDU. 

If the MS uses format 2, the data priority blocks shall be included in decreasing order of data priority. 

The MS may use either format 1) or format 2) as appropriate to its capabilities or to the information in the 
DATA-IN-BUFFER signal. 

NOTE: When the MS indicates its data priority requirements, it indicates only the data priority requirements for 
the address with which the L2 -DATA-PRIORITY PDU will be sent. The ISSI and its associated ASSI are 
regarded as equivalent for the purposes of this procedure. Similarly, an event label and its corresponding 
address are regarded as equivalent for the purposes of this procedure. However, an MS is not permitted to 
combine any data priority requirements for its SMI with requirements for an SSI (or vice versa), and it is 
not permitted to combine the data priority requirements for multiple TSI families. 

23.4.7.2.2 Content of L2-DATA-PRI0RITY message if using format 1 ) 

If the MS -MAC uses format 1), it shall set the "residual data priority" to the maximum data priority indicated by the 
LLC for the appropriate address and endpoint identifier (unless the MS-MAC is sending the L2-DATA-PRI0RITY 
message when there is only data of undefined data priority in the LLC queue, in which case the MS-MAC may set the 
"residual data priority" to the MS default data priority). 

NOTE: The "residual data priority" indicates the data priority information for the data in the LLC queue (for this 
address on this channel), irrespective of whether the MS has already been granted some future slots. 

23.4.7.2.3 Content of L2-DATA-PRI0RITY message if using format 2) 

If the MS-MAC uses format 2) then: 

• if the MS is on a 7i/4-DQPSK channel, the appropriate number of slots in each data priority block is known 
from the information about the amount of queued data per data priority, provided in the DATA-IN -BUFFER 
signal received from the LLC; 

• if the MS is on a D8PSK or QAM channel, the appropriate number of slots in each data priority block shall be 
estimated from the information about the amount of queued data per data category and per data priority, 
provided in the DATA-IN-BUFFER signal received from the LLC. The expected number of slots to send the 
data for a particular data priority depends on both the amount of data and the modulation level (and coding rate 
for QAM) with which the MS -MAC currently expects to send the data. If there is data for more than one data 
category for this data priority, the expected modulation level (and coding rate for QAM) may be different for 
the different data categories; in this case, the MS-MAC shall estimate the number of slots required at each 
modulation level (and coding rate for QAM) and shall indicate the total in the "number of slots" element for 
that data priority; see also clause 23.4.9. 

NOTE 1: The "number of slots" element indicates the number of slots that the MS needs to send the data for this 
data priority (for this address on this channel), irrespective of whether the MS has already been granted 
some future slots. 
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The MS-MAC may indicate a data priority requirement of one subslot, or one or more full slots (as shown in 
clause 21 .2.4. 1). The required number of slots is coded in a non-linear format. If the MS's requirement cannot be 
represented exactly within the defined format: 

• the MS-MAC should round up to the next higher valid number of slots for data priorities above the MS default 
data priority; 

• the MS-MAC may round down to the next lower valid number of slots for data priorities below the MS default 
data priority. 

In most cases, the MS-MAC should choose the number of data priority blocks such that fragmentation of the message 
will not be needed. For example: 

• if the message will be sent by random access on a 7i/4-DQPSK or D8PSK channel then: 

if the MS has an event label, there is space for the maximum number (i.e. 7) of data priority blocks; 

if the MS does not have an event label, there is space for up to 6 data priority blocks before 
fragmentation becomes necessary; 

• if the message will be sent by random access on a QAM channel then: 

if the MS has an event label, there is space for up to 4 data priority blocks before fragmentation becomes 
necessary; 

if the MS does not have an event label, there is space for up to 2 data priority blocks before 
fragmentation becomes necessary. 

EXAMPLE: If the MS is on a QAM channel and does not have an event label, and the LLC indicates data at 
data priority levels 6, 5, 4 and 3, the MAC may include data priority blocks for data priorities 6 
and 5, and then set the "residual data priority" to 4 in the L2-DATA-PRIORITY message. 

If the LLC is currently indicating data for N data priorities (with 1 < N < 7) and there would be space for the MS to 
send data priority blocks for all N data priorities without fragmentation, the MS -MAC may either: 

i) include N - 1 data priority blocks (one for each data priority except the lowest data priority in the LLC queue) 
and then set the "residual data priority" to the lowest of the data priorities in the LLC queue; or 

ii) include N data priority blocks (one for each data priority in the LLC queue) and then set the "residual data 
priority" to the MS default data priority. 

NOTE 2: The MS designer should choose an appropriate method. (The choice of method may depend on the pattern 
of data and/or on whether the lowest of the data priorities in the LLC queue is more than, or less than, the 
MS default data priority.) 

NOTE 3: The maximum number of data priority blocks is 7. Therefore, if the LLC is currently indicating data for 
all 8 data priorities, the MAC cannot use method ii). 

If the MS requires more than 68 slots for a data priority, the MS-MAC may send more than one data priority block for 
that data priority. Otherwise it may set the "residual data priority" to the highest data priority for which more than 
68 slots is required, in which case it should not include any data priority blocks for any lower data priorities. 

23.4.7.2.4 Sending L2-DATA-PRI0RITY message 

When the MS-MAC sends an L2-DATA-PRIORITY message, it shall issue the message to the LLC in a 
TLE-UNITDATA request primitive. The MS-MAC shall set the PDU priority level in the request primitive to the PDU 
priority of the highest priority message in the LLC buffer for this address and channel, as indicated in the 
DATA-IN-BUFFER signal from the LLC. 

NOTE 1 : Therefore the LLC will normally send the L2-D ATA-PRIORITY PDU on reception of the next 

MAC -READ Y signal (dehvering the PDU to the MAC using a TMA-UNITDATA request primitive). 

It is recommended that the number of repetitions of the layer 2 signalling message is normally set to 0. 
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NOTE 2: In some cases the MS-MAC may choose to set the number of repetitions to more than 0; for example, it 
could choose to do so if the required data priority has increased and the MS has a large quantity of data to 
send with that increased data priority. However the MS designer should note that excessive repetition of 
the L2-DATA-PRIORITY message may reduce the MS's overall data throughput. 

If the MS -MAC sends an L2-DATA-PRIORITY message, and there is a significant change in the data priority 
requirements before the MS-MAC receives a TLE-REPORT indication primitive reporting completion of the transfer 
(either successful or failed transfer), the MS-MAC may cancel the ongoing transfer using the TLE-CANCEL request 
primitive and then send a revised L2 -DATA-PRIORITY message. 

After sending an L2 -DATA-PRIORITY message and receiving a TLE-REPORT indication primitive reporting first 
complete transmission of the message, the MS-MAC shall record the "residual data priority" in the 
L2-DATA-PRI0RITY message and the highest "temporary data priority" in any data priority blocks. Also, if the 
L2-DATA-PRI0RITY message contained data priority block(s), the MS-MAC shall maintain the current value of the 
"derived data priority". The "derived data priority" is the data priority that the MS-MAC regards as applying at the 
current moment for this address and channel. It is calculated by counting the number of reserved slots and subslots used 
for this address on this channel since the first transmission of the L2 -DATA-PRIORITY message and comparing this 
with the numbers of slots and subslots given in the data priority block(s) as follows: 

• after the first complete transmission of the L2-DATA-PRIORITY message, the MS-MAC shall set the 
"derived data priority" to the "temporary data priority" in the first data priority block; 

• then, after each reserved slot or subslot until the "derived data priority" is set to the "residual data priority", the 
MS -MAC shall perform the following or equivalent check: 

if the reserved capacity used for this address on this channel since the first complete transmission of the 
L2-DATA-PRIORITY message > capacity requested for the "derived data priority" and for any higher 
temporary data priorities then: 

■ if there are more data priority blocks, the MS -MAC shall set the "derived data priority" to the 
"temporary data priority" in the next data priority block; 

■ otherwise the MS-MAC shall set the "derived data priority" to the "residual data priority". 

EXAMPLE: For example, if the MS included one data priority block with temporary data priority DPRI 

requiring 6 slots then the "derived data priority" is set to DPRI until 6 reserved slots have been 
used and then reverts to the residual data priority. If the MS included two data priority blocks with 
temporary data priorities DPRIa and DPRIb, requiring 4 slots and 6 slots respectively, then the 
"derived data priority" is set to DPRIa until 4 reserved slots have been used, is then set to DPRIb 
until a further 6 reserved slots have been used, and then reverts to the residual data priority. 

23.4.7.3 Expiry of short-term data priority information 

The data priority information included in the L2-DATA-PRIORITY message is only temporary. The SNDCP in the MS 
receives the value of the layer 2 data priority lifetime timer from the SwMI when it receives the network default data 
priority or negotiates a specific MS default data priority. The SNDCP also receives the value of the layer 2 data priority 
signalling delay (and the data priority random access delay factor). The higher layers inform the MS-MAC about the 
values of the layer 2 data priority lifetime and layer 2 data priority signalling delay timers (and the data priority random 
access delay factor) using the TMC -CONFIGURE request primitive. 

After sending an L2 -DATA-PRIORITY message and receiving a TLE-REPORT indication primitive reporting first 
complete transmission of the message, the MS-MAC shall start the layer 2 data priority lifetime timer T.222. It shall 
also start the layer 2 data priority signalling delay timer T.223. 

NOTE 1: Timer T.223 is used in the criteria for sending an L2 -DATA-PRIORITY message (see clause 23.4.7.4). 
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The MS-MAC shall assume that the information sent in the L2-DATA-PRIORITY message applies until one of the 
following occurs: 

a) a time T.222 has elapsed since the MS -MAC received the TLE-REPORT indication primitive reporting first 
complete transmission of the message; or 

b) the MS-MAC initiates the random access procedure for this address on this channel and has transmitted a first 
random access request; or 

c) the MS -MAC sends another L2-DATA-PRIORITY message for this address on this channel and has received 
a TLE-REPORT indication primitive reporting that the message has been completely transmitted once. 

In case a), the MS-MAC shall assume that the MS's current data priority for this address and channel is the MS default 
data priority. 

In case b), after transmitting the first random access request, the MS -MAC shall assume that its current data priority for 
this address and channel is the MS default data priority. (If the random access request carried an L2-DATA-PRI0RITY 
message then the data priority information in that L2-DATA-PRI0RITY message shall apply, and timers T.222 and 
T.223 shall be started, when the MS -MAC receives the TLE-REPORT indication primitive from the LLC reporting first 
complete transmission of the message as in case c).) 

In case c), when the MS-MAC receives the TLE-REPORT indication primitive reporting first complete transmission of 
the new L2 -DATA-PRIORITY message, it shall assume that the information sent in the new L2-DATA-PRIORITY 
message applies and shall start the layer 2 data priority lifetime timer T.222 and the layer 2 data priority signalling delay 
timer T.223. 

NOTE 2: If the message is not completely transmitted at least once, the MS-MAC assumes that the information sent 
in the previous L2-DATA-PRIORITY message applies until one of criteria a), b) or c) occurs. 

23.4.7.4 Criteria for sending L2-DATA- PRIORITY message 

The MS-MAC shall not send the L2 -DATA-PRIORITY message if: 

• it has not received a SYSINFO or SYSINFO-Q PDU from the BS indicating that the BS supports data priority 
(using the "extended services broadcast" element in the SYSINFO or SYSINFO-Q PDU); or 

• the MS default data priority last provided by the higher layers in the TMC-CONFIGURE request primitive 
was set to "not applicable". 

The MS-MAC should not send the L2-DATA-PRIORITY message if it has already been granted capacity sufficient and 
suitable for its current reserved access requirements for this address on this channel. 

NOTE 1 : On a 7i/4-DQPSK or D8PSK channel, or if the MS does not currently have any schedules in operation, the 
MS-MAC should not send the L2-DATA-PRIORITY message if it has already been granted capacity 
sufficient for its current reserved access requirements for this address on this channel. On a QAM 
channel, if the MS has schedule(s) in operation and also has unscheduled data to send, and has been 
granted capacity by multiple slot granting, then it may choose to send the L2-DATA-PRIORITY message 
if the granted capacity matches only its expected future scheduled access requirements. 

Also, if the DATA-IN-BUFFER signal indicates that the next PDU that the LLC expects to send for this address on this 
channel does not contain packet data, the MS-MAC should not send the L2-DATA-PRIORITY message at this time 
(see note 2) unless: 

• the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and channel is data 
priority 7; and 

• the amount of data indicated in the DATA-IN -BUFFER signal for data priority 7 would not fit within the next 
MAC block that the MS will be transmitting on this channel (either within the next granted slot or subslot, or 
within the random access request if appropriate); and 

• the MS has not already been granted capacity sufficient and suitable for the amount of data with data 
priority 7. 
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NOTE 2: The MS-MAC may send the L2-DATA-PRIORITY message if both PDUs would fit within the next 
MAC block that the MS will be transmitting on this channel. Also, if the MS -MAC has issued an 
L2-LINK-FEEDBACK-INFO message to the LLC, and the MS supports the combined 
L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITY PDU (see clause 22.3. L7.3), the 
MS-MAC may send an L2 -DATA-PRIORITY message containing only a "residual data priority". 

Subject to the above constraints, the MS-MAC may send the L2-DATA-PRI0RITY message if any of the following 
criteria are satisfied: 

• the MS default data priority currently applies for this address on this channel (i.e. the MS-MAC has not sent an 
L2-DATA-PRI0RITY message or timer T.222 has expired or the MS-MAC has transmitted a random access 
request since the last L2-DATA-PRIORITY message), or the MS is initiating the random access procedure, 
and: 

the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and channel is a 
defined value and is not equal to the MS default data priority (see note 3); or 

if the MS supports format 2): the DATA-IN-BUFFER signal indicates data for this address and channel 
with a defined data priority not equal to the MS default data priority (see note 4); 

NOTE 3: When the maximum data priority indicated in the DATA-IN-BUFFER signal is a defined value less than 
the MS default data priority, the MS-MAC may decide not to send the L2-DATA-PRI0RITY message if 
there is only a small amount of data to send at less than the MS default data priority; this may be 
preferable particularly if the MS is not initiating the random access procedure. 

NOTE 4: In the case indicated, transmission of the L2-D ATA-PRIORITY message is permitted if the maximum 

data priority indicated in the DATA-IN -BUFFER signal is equal to the MS default data priority but there 
is data with data priority lower than the MS default data priority. Alternatively, the MS may wait until the 
maximum data priority indicated in the DATA-IN-BUFFER signal is not equal to the MS default data 
priority before sending the L2-D ATA-PRIORITY message; this may be preferable particularly if the MS 
is not initiating the random access procedure. 

• information sent in the last L2-DATA-PRIORITY message for this address on this channel still applies and 
any of the following criteria a), b) or c) are satisfied: 

a) the last L2 -DATA-PRIORITY message contained only a "residual data priority" and the maximum data 
priority indicated in the DATA-IN -BUFFER signal for this address and channel is a defined value and is 
greater than the "residual data priority"; or 

b) the last L2-D ATA-PRIORITY message contained data priority block(s) and: 

i) the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and channel 
is a defined value and is greater than the highest "temporary data priority" in the data priority 
block(s) in the last L2-DATA-PRIORITY message and is greater than the current "derived data 
priority"; or 

ii) the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and channel 
is a defined value and is greater than the current "derived data priority"; or 

iii) as an alternative option to ii), the maximum data priority indicated in the DATA-IN -BUFFER 
signal for this address and channel will be greater than the "derived data priority" that will apply 
after use of the next reserved slot or subslot; 

c) a time T.223 has elapsed since the MS-MAC received the TLE-REPORT indication primitive reporting 
first complete transmission of the message and either: 

■ there has been a change in the data priority information since the last L2-D ATA-PRIORITY 

message (see below); or 

■ the last L2-DATA-PRI0RITY message was not sent by successful random access; however, the 
MS-MAC shall not send the same or equivalent information more than a total of N. 223 times 
(see note 7). 
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NOTE 5: In cases a) and b), the MS-MAC should not send the L2 -DATA-PRIORITY message if it has already 
been granted capacity sufficient and suitable for its reserved access requirements for the data with data 
priority greater than the "residual data priority" or highest "temporary data priority" or "derived data 
priority" as appropriate in the specified criteria. 

NOTE 6: The MS may send the L2 -DATA-PRIORITY message immediately if criterion a) or criterion b)i) is 
satisfied. The MS is also permitted to send the L2-DATA-PRIORITY message immediately if 
criterion b)ii) or b)iii) is satisfied. However the MS designer should note that care needs to be taken to 
avoid excessive use of the L2-DATA-PRIORITY message. Excessive use of the L2-D ATA-PRIORITY 
message (in an attempt to track fluctuating data priority requirements too closely) may reduce the MS's 
overall data throughput. 

NOTE 7: If an L2 -DATA-PRIORITY message was sent by stealing or reserved access, or if the transfer failed, the 
MS-MAC may send another L2 -DATA-PRIORITY message after expiry of timer T.223 (and possibly 
again after the next expiry of timer T.223 if the L2-D ATA-PRIORITY message was again sent by 
stealing or reserved access) - within the limit defined by N.223; see point c) above. This may apply 
particularly if the number of repetitions of the layer 2 signalling message was 0. However, the MS-MAC 
should not continually send the same or equivalent information after each expiry of timer T.223 since this 
may reduce the MS's overall data throughput. Also, if the number of repetitions of the layer 2 signalling 
message was not 0, the MS-MAC should reduce the value of N.223 accordingly. 

In case c) above, the MS designer should choose criteria for the MS-MAC to send the L2 -DATA-PRIORITY message 
after expiry of the layer 2 data priority signalling delay timer T.223. As always, the MS-MAC may send the 
L2-D ATA-PRIORITY message if criterion a) or b) is satisfied. Additionally, the MS-MAC may regard the following or 
equivalent cases as constituting a change in the data priority information since the last L2-D ATA-PRIORITY message 
such that an L2-D ATA-PRIORITY message may be sent after expiry of timer T.223: 

• the last L2-D ATA-PRIORITY message contained data priority block(s) and the MS-MAC deduces from the 
information in the DATA-IN -BUFFER signal for this address and channel that the LLC now has a significant 
amount of new data to send for the data priorities appropriate to those data priority block(s); or 

• the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and channel is a 
defined value and is less than: 

the "residual data priority", if the last L2-DATA-PRIORITY message contained only a "residual data 
priority"; or 

the current "derived data priority", if the last L2-D ATA-PRIORITY message contained data priority 
block(s). 

In the second two cases, the MS-MAC may decide not to send the L2-D ATA-PRIORITY message if there is only a 
small amount of data to be sent with the lower data priority. 

NOTE 8: The MS designer should note that care needs to be taken to avoid excessive use of the 

L2-D ATA-PRIORITY message, while at the same time avoiding delays in receiving high data-priority 
capacity when it is required and avoiding receiving too much capacity with higher data priority than 
needed. Excessive use of the L2-D ATA-PRIORITY message (in an attempt to track fluctuating data 
priority requirements too closely) may reduce the MS's overall data throughput; this applies particularly if 
the MS will send the L2-D ATA-PRIORITY message using reserved access. 

23.4.7.5 Reverting to random access if MS supports data priority 
23.4.7.5.1 General 

As defined in clause 23.5.1.4.3, the MS-MAC may initiate the random access procedure immediately if the MS has 
individually addressed unscheduled signalling messages to send, and the MS -MAC does not currently have any 
capacity granted for this address on this control channel, and either: 

a) it has not already sent a PDU indicating a reservation requirement for this address on this control channel; or 

b) the DATA-IN-BUFFER signal from the LLC indicates that a new emergency unscheduled message has been 
received from layer 3. 
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Also, the MS-MAC may initiate the random access procedure if the MS has unscheduled signalling messages to send, 
and the MS-MAC has sent a PDU indicating a reservation requirement for this address on this control channel and does 
not currently have any capacity granted for this address on this control channel, and the timing criteria in 
clause 23.5.2.4.1 are satisfied. 

NOTE 1: The MS-MAC may also initiate the random access procedure if the MS has scheduled signalling 

messages to send for this address on this control channel and the criteria in clause 23.5.2.4.2 are satisfied. 

The procedure in clause 23.5.2.4.1 requires the MS -MAC to continue to wait when it receives a basic slot granting 
element for this address on this channel containing the instruction to "Wait for another slot grant" (except in case of 
emergency); the BS may send the instruction to "Wait for another slot grant" repeatedly to the MS, in which case the 
MS-MAC continues to wait. This procedure generally applies also when the MS is sending packet data. However, if the 
MS supports data priority (and the SNDCP is in the READY state), the MS-MAC is permitted to initiate the random 
access procedure if the criteria in clause 23.4.7.5.2 or 23.4.7.5.3 are satisfied - even though the criteria in 
clause 23.5.2.4.1 may not be satisfied. 

NOTE 2: If the criteria in clause 23.5.2.4.1 are satisfied before the criteria in clause 23.4.7.5.2 or 23.4.7.5.3 are 
satisfied, the MS-MAC may initiate the random access procedure in the usual way. 

The procedure in clause 23.4.7.5.2 gives criteria based on an increase in the MS's data priority requirements. This 
procedure may allow the MS-MAC to initiate the random access procedure earlier than in clause 23.5.2.4.1 in order to 
indicate its increased data priority requirements (for example, when the BS has sent the instruction to "Wait for another 
slot grant" because it is granting slots to other MS(s) with higher data priority than the MS indicated in its last 
L2-DATA-PRI0RITY message). 

The procedure in clause 23.4.7.5.3 gives criteria if the next message that the MS expects to send does not contain 
packet data, for example, if the next message is an acknowledged basic link message or link adaptation feedback 
message. An uplink message that does not contain packet data has undefined data priority (except optionally for PDU 
priority 7), so it takes the data priority of any packet data behind it in the LLC queue by default. However, the 
procedure in clause 23.4.7.5.3 may allow the MS-MAC to initiate the random access procedure earlier than in 
clause 23.5.2.4.1 in order to send the non-packet-data message (for example, when the BS has sent the instruction to 
"Wait for another slot grant" because it is granting slots to other MS(s) with higher data priority than the MS indicated 
in its last L2-DATA-PRI0RITY message). 

23.4.7.5.2 Reverting to random access to send L2- DATA-PRIORITY message 

If the following criteria are all satisfied then the MS-MAC may initiate the random access procedure (see 
clause 23.5.1): 

a) the MS-MAC has received a SYSINFO or SYSINFO-Q PDU from the BS indicating that the BS supports 
data priority; 

b) the MS default data priority last provided by the higher layers in the TMC-CONFIGURE request primitive 
was set to a defined value (i.e. was not set to "not applicable"); 

c) the MS-MAC has sent a PDU (MAC-ACCESS, MAC-DATA, MAC-U-BLCK, MAC-END-HU or 
MAC -END) indicating a reservation requirement for this address on this control channel; 

d) the MS-MAC does not currently have any capacity granted for this address on this control channel; 

e) the MS default data priority currently applies for this address on this channel and the maximum data priority 
indicated in the DATA-IN -BUFFER signal for this address and channel is a defined value and is greater than 
the MS default data priority; or 

information sent in the last L2-DATA-PRIORITY message for this address on this channel still applies and 
either: 

i) the last L2 -DATA-PRIORITY message contained only a "residual data priority" and the maximum data 
priority indicated in the DATA-IN -BUFFER signal for this address and channel is a defined value and is 
greater than the "residual data priority"; or 
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ii) the last L2-DATA-PRIORITY message contained data priority block(s) and: 

■ the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and channel 
is a defined value and is greater than the highest "temporary data priority" in the data priority 
block(s) in the last L2-DATA-PRIORJTY message and is greater than the current "derived data 
priority"; or 

■ the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and channel 
is a defined value and is greater than the current "derived data priority"; 

f) a time T has elapsed since the MS-MAC last sent a PDU on this control channel for this address (i.e. either a 
MAC-ACCESS, MAC-DATA or MAC-U-BLCK PDU with this address or a MAC-FRAG, MAC-END or 
MAC-END-HU PDU relating to this address), where T is defined as follows: 

ifDF = 0thenT = T.206; 

if DF > then T = ( 8 - MDP ) X DF X T.206, 

where: 

MDP is the maximum data priority indicated in the DATA-IN-BUFFER signal for this address and 
channel; 

DF is the current value of the data priority random access delay factor (received from the SwMI at 
SNDCP level and provided to the MS-MAC using the TMC-CONFIGURE request primitive); 

T.206 is the value of the reserved access waiting time-out (see annex B); and 

T is measured in terms of downlink signalling frames for this control channel (as for timer T.206). 

NOTE 1 : When appropriate, this procedure allows the MS to revert to random access after time T has elapsed even 
if the MS-MAC has received a basic slot granting element for this address on this control channel 
containing the instruction to "Wait for another slot grant". Therefore, in the cases listed in criterion e), 
this procedure may permit the MS to revert to random access in order to send an L2-DATA-PRIORITY 
message even though the criteria in clause 23.5.2.4.1 may not be satisfied. 

NOTE 2: The MS is permitted to revert to random access to send the L2-DATA-PRIORITY message after time T 
has elapsed if any of the criteria in e) are satisfied. However the MS designer should note that excessive 
sending of the L2-DATA-PRIORITY message by random access (in an attempt to track fluctuating data 
priority requirements too closely) may reduce the performance of the random access channel. 

If the MS-MAC decides to initiate the random access procedure and wishes to send an L2-DATA-PRIORITY message, 
it should issue the L2-DATA-PRIORITY message to the LLC in a TLE-UNITDATA request primitive and then issue 
the MAC-READY signal. 

NOTE 3: In an implementation, the MAC should not issue the MAC-READY signal until the LLC has had time to 
process the TLE-UNITDATA request primitive. 

If the MS-MAC decides to initiate the random access procedure based on the above criteria being satisfied, but it does 
not wish to send an L2 -DATA-PRIORITY message, it should issue the MAC-READY signal to the LLC since there 
may be a PDU in the LLC queue that can be sent within the MAC-ACCESS PDU. For example, this may apply if the 
maximum data priority indicated in the DATA-IN -BUFFER signal for this address and channel is the MS default data 
priority - since the action of sending a random access request implicitly sets the MS's current data priority for this 
address and channel to the MS default data priority (see clause 23.4.7.3). Or the MS-MAC may decide not to send the 
L2-DATA-PRI0RITY message at this time if the amount of data indicated in the DATA-IN-BUFFER signal for the 
maximum data priority for this address and channel could be sent within the random access request. 

The random access request shall be sent on SCH/HU (for a 7i/4-DQPSK or D8PSK channel) or on SCH-Q/RA (for a 
QAM channel) using the MAC- ACCESS PDU, containing a TM-SDU if appropriate. If the MS has any further 
signalling ready to send for this address on this control channel, the MS-MAC shall include a request for reserved 
capacity ("reservation requirement" element) in the MAC-ACCESS PDU. 

NOTE 4: If the MS was in the process of sending a fragmented message at the time when it decides to initiate the 

random access procedure, it should discard the partially sent TM-SDU. (Alternatively the MS may choose 
not to initiate the random access procedure in this case.) 
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23.4.7.5.3 Reverting to random access to send non-packet-data message 

If the following criteria are all satisfied then the MS-MAC may initiate the random access procedure (see 
clause 23.5.1): 

a) the MS-MAC has received a SYSINFO or SYSINFO-Q PDU from the BS indicating that the BS supports 
data priority; 

b) the MS default data priority last provided by the higher layers in the TMC-CONFIGURE request primitive 
was set to a defined value (i.e. was not set to "not applicable"); 

c) the MS-MAC has sent a PDU (MAC-ACCESS, MAC-DATA, MAC-U-BLCK, MAC-END-HU or 
MAC-END) indicating a reservation requirement for this address on this control channel; 

d) the MS-MAC does not currently have any capacity granted for this address on this control channel; 

e) the DATA-IN -BUFFER signal indicates that the next PDU that the LLC expects to send for this address on 
this control channel does not contain packet data; 

f) a time T has elapsed since the MS-MAC last sent a PDU on this control channel for this address (i.e. either a 
MAC-ACCESS, MAC-DATA or MAC-U-BLCK PDU with this address or a MAC-FRAG, MAC-END or 
MAC-END-HU PDU relating to this address), where T is defined as follows: 

ifDF = 0thenT = T.206; 

if DF > then T = 2 X DF X T.206, 

where: 

DF is the current value of the data priority random access delay factor (received from the SwMI at 
SNDCP level and provided to the MS-MAC using the TMC-CONFIGURE request primitive); 

T.206 is the value of the reserved access waiting time-out (see annex B); and 

T is measured in terms of downlink signalling frames for this control channel (as for timer T.206). 

If the MS -MAC decides to initiate the random access procedure based on the above criteria being satisfied, it should not 
send an L2-DATA-PRIORITY message at this time (unless the maximum data priority indicated in the 
DATA-IN -BUFFER signal for this address and channel is data priority 7 and the amount of data indicated in the 
DATA-IN-BUFFER signal for data priority 7 would not fit within the random access request). 

NOTE 1: If the MS-MAC has issued an L2-LINK-FEEDBACK-INFO message to the LLC, and the MS supports 
the combined L2-LINK-FEEDBACK-INFO-AND-RESIDUAL-DATA-PRIORITY PDU (see 
clause 22.3. L7.3), the MS-MAC may send an L2-DATA-PRI0RITY message containing only a "residual 
data priority". 

The random access request shall be sent on SCH/HU (for a 7i/4-DQPSK or D8PSK channel) or on SCH-Q/RA (for a 
QAM channel) using the MAC- ACCESS PDU, containing a TM-SDU if appropriate. If the MS has any further 
signalling ready to send for this address on this control channel, the MS-MAC shall include a request for reserved 
capacity ("reservation requirement" element) in the MAC-ACCESS PDU. 

NOTE 2: If the MS was in the process of sending a fragmented message at the time when it decides to initiate the 

random access procedure, it should discard the partially sent TM-SDU. (Alternatively the MS may choose 
not to initiate the random access procedure in this case.) 
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23.4.7.6 BS procedures for data priority 

23.4.7.6.1 Packet data on uplink 

If the BS supports data priority, it should use any: 

• information about the defauh data priority; and 

• short-term data priority information received in L2-DATA-PRIORITY messages, 

for the MSs on a shared channel used for packet data in deciding when to grant slots to those MSs. The BS may also use 
uplink fragmentation as a criterion in deciding when to grant slots to MSs (see note). The methods used by the BS for 
scheduling of the uplink channel are outside the scope of the present document. 

NOTE: If an MS on a packet data channel has a message to send that does not contain packet data (for example, 
an acknowledged basic link message), it may be permitted to use random access to send the message; see 
clauses 23.4.7.5.3 and 23.5.1.4.3. An uplink message that does not contain packet data has undefined data 
priority (except optionally for PDU priority 7) and may require fragmentation. The BS may choose to 
give high priority to fragmented messages when granting slots. 

The BS should assume that the default data priority applies for an MS unless it has received an L2-DATA-PRIORITY 
message from that MS. 

After receiving an L2-DATA-PRI0RITY message from an MS, the BS should assume that the information sent in the 
L2-DATA-PRI0RITY message applies while that MS is sending packet data on that channel, until one of the following 
occurs: 

a) a time corresponding to the layer 2 data priority lifetime timer for that MS has elapsed since receipt of the 
L2-DATA-PRI0RITY message; or 

b) the BS receives a MAC-ACCESS PDU from that MS, sent by random access on that channel; or 

c) the BS receives another L2 -DATA-PRIORITY message from that MS on that channel. 

In case a), the BS should assume that the default data priority applies for that MS until it receives another 
L2-DATA-PRIORITY message from that MS. 

In case b), if the MAC-ACCESS PDU contained an L2-DATA-PRIORITY message, the BS should assume that the 
information sent in the L2-DATA-PRI0RITY message applies as in case c); otherwise the BS should assume that the 
default data priority applies for that MS until it receives another L2-DATA-PRIORITY message from that MS. 

In case c), the BS should assume that the information sent in the new L2-DATA-PRIORITY message applies until one 
of cases a), b) or c) occurs as above. 

The "data priority details" element sent by the BS's SNDCP entity in some SNDCP PDUs contains the values of the 
layer 2 data priority lifetime (timer T.222) and the layer 2 data priority signalling delay (timer T.223) to be used by the 
addressed MS(s). The "data priority details" element also allows control of how soon the MS(s) may revert to random 
access to send the L2-DATA-PRIORITY message or a message that does not contain packet data, by using the data 
priority random access delay factor (see clause 23.4.7.5). The methods used by the BS to choose the values of these 
parameters are outside the scope of the present document. 

23.4.7.6.2 Packet data on downlink 

The methods used by the BS for scheduling of data packets on the downUnk channel are outside the scope of the present 
document. 
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23.4.8 Napping 
23.4.8.1 General 

As described in clause 23.7.6, the MS may use energy economy mode when on the MCCH or a common SCCH if it has 
negotiated an energy economy group by an MM message exchange. 

The napping procedure is an independent procedure which may apply when the MS is on an assigned channel. It may 
provide the MS with some opportunities for neighbour cell monitoring, sectored channel monitoring, main carrier 
monitoring and/or background scanning, even when the MS is on a multi-slot assigned channel; also it may allow some 
battery economy in the MS. However it generally requires more reception than when the MS is using energy economy 
mode. 

NOTE 1 : The napping procedure does not apply on the MCCH or on a common SCCH. 

When the BS sends an augmented channel allocation for an assigned channel, it indicates whether use of the napping 
procedure is permitted on the assigned channel. If use of the napping procedure is permitted, the BS normally includes 
the appropriate napping information for use on the assigned channel. The napping information comprises: 

• the "napping reception timeslots" i.e. a timeslot bit map indicating the downlink slot or slots that the MS is 
required to receive in the napping reception frames when the MS is in napping mode (but limited to the slots 
appropriate to the downlink assigned channel); 

• the "napping reception frames" when in napping mode, specified as either: 

all downlink TDMA frames; or 

every two TDMA frames (so that the MS is only required to receive in either odd-numbered or 
even-numbered TDMA frames); or 

every three TDMA frames (so that the MS is only required to receive in every third TDMA frame); 

• the value of the napping timer T.226; and 

• a flag indicating whether the MS may use reduced reception in frame 18 when not in napping mode. 

Alternatively, the BS may indicate that any napping information for the current channel (i.e. the channel on which the 
channel allocation was received) may be used on the assigned channel. For example, this may apply in the case of a 
channel replacement on a group address. 

The napping method allows the MS to use napping mode when it has not sent or received a message recently i.e. during 
long gaps between transmissions (based on inactivity timer T.226). 

Also the BS may instruct the MS dynamically that the MS may return to napping mode immediately (see note 2). This 
dynamic instruction may be used to allow the MS to use napping mode temporarily during short gaps in transmission. It 
may also be used to allow a fast return to napping mode at the end of the current data. The BS informs the MS that it 
may return to napping mode immediately by setting the "immediate napping permission flag" element to 1 (see note 2). 
This element is included in: 

• MAC -RESOURCE and MAC-END PDUs sent using 71/8-D8PSK or QAM modulation; and 

• MAC-D-BLCK PDUs. 

When the MS receives a MAC-RESOURCE or MAC-END PDU sent using 7i/4-DQPSK modulation, it regards the 
PDU as not giving immediate napping permission. 

NOTE 2: The MS does not return to napping mode on receipt of a PDU with the "immediate napping permission 
flag" set to 1 if it has received a PDU on a different address not giving immediate napping permission. 
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23.4.8.2 MS criteria for napping 



If the MS supports napping, and is on an assigned channel on which use of the napping procedure is permitted (i.e. if 
the channel was allocated with an augmented channel allocation with "napping status" element set to OI2 or IO2), the 
MS-MAC shall maintain a record of whether it is currently either: 

• required to be in full reception mode; or 

• permitted to be in napping mode, 

on that assigned channel. This is specified in terms of whether each of its valid addresses (individual and group 
addresses) are currently "eligible for napping" or "ineligible for napping" on the assigned channel. As defined below, 
the MS -MAC is not permitted to use napping mode unless all its valid addresses are currently "eligible for napping" on 
this channel (plus some additional criteria). 

EXAMPLE: On receipt of a PDU for any of the MS's valid addresses, and that does not give immediate 

napping permission (i.e. that either does not contain the "immediate napping permission flag" or 
contains the "immediate napping permission flag" set to 0), the MS is required to use full reception 
mode. A PDU giving immediate napping permission overrides a previous instruction not to nap 
received on the same address; however it does not override a previous instruction not to nap 
received on a different address. 

NOTE 1: The ISSI and its associated ASSI are regarded as equivalent for the purposes of this procedure. Similarly, 
an event label and its corresponding address are regarded as equivalent for the purposes of this procedure. 

The MS-MAC shall regard all its addresses as "ineligible for napping" on the assigned channel when it first moves to 
the assigned channel. The MS-MAC shall then maintain a record of whether an address is currently "eligible for 
napping" or "ineligible for napping" on the assigned channel as follows: 

a) If the MS-MAC receives a MAC -RESOURCE PDU on this channel and containing that address then: 

if the MAC-RESOURCE PDU either does not contain the "immediate napping permission flag" or 
contains the "immediate napping permission flag" set to 0, the MS-MAC shall regard that address as 
currently "ineligible for napping"; 

if the MAC-RESOURCE PDU contains the "immediate napping permission flag" set to 1, the MS-MAC 
may regard that address as currently "eligible for napping". 

b) If the MS-MAC receives a MAC -END PDU on this channel and relating to that address then: 

if the MAC-END PDU either does not contain the "immediate napping permission flag" or contains the 
"immediate napping permission flag" set to 0, the MS-MAC shall regard that address as currently 
"ineligible for napping"; 

if the MAC-END PDU contains the "immediate napping permission flag" set to 1, the MS-MAC may 
regard that address as currently "eligible for napping". 

c) If the MS-MAC receives a MAC-D-BLCK PDU on this channel and containing that address then: 

if the MAC-D-BLCK PDU contains the "immediate napping permission flag" set to 0, the MS-MAC 
shall regard that address as currently "ineligible for napping"; 

if the MAC-D-BLCK PDU contains the "immediate napping permission flag" set to 1, the MS-MAC 
may regard that address as currently "ehgible for napping". 

d) If a time T.226 has elapsed since the MS moved to the channel and the MS -MAC has not sent or received a 
PDU on this channel using that address, and the MS does not have any reserved capacity on this channel 
granted for that address, then the MS -MAC may regard that address as currently "eligible for napping". 

e) If a time T.226 has elapsed since the MS -MAC last sent or received a PDU on this channel using that address 
or relating to that address, and the MS does not have any reserved capacity on this channel granted for that 
address, then the MS-MAC may regard that address as currently "eligible for napping". 
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NOTE 2: In cases a), b) and c), if the "immediate napping permission flag" is set to 1, the MS-MAC may regard the 
address as "eligible for napping" irrespective of whether the MS has been granted reserved capacity for 
that address. 

The MS-MAC shall enter full reception mode when it first moves to the assigned channel. 

The MS-MAC shall enter (or remain in) full reception mode on the assigned channel when any of the following events 
occurs: 

• any of its valid addresses become "ineligible for napping" on this channel; or 

• it initiates the random access procedure on this channel; or 

• it receives a MAC-RESOURCE PDU on this channel containing one of its addresses or event labels, and 
containing "Length indication" set to 11 1 1 1 12 (indicating the start of fragmentation); or 

• it enters traffic mode on this channel for transmission and/or reception (see clause 23.8). 

When the MS -MAC is in full reception mode on the assigned channel, it may enter napping mode on the assigned 
channel if: 

• all its valid addresses are currently "eligible for napping" on this channel; and 

• it is not currently making a random access attempt on this channel (see note 3); and 

• it is not currently performing reconstruction on this channel of a downlink TM-SDU for any of its addresses or 
event labels (see note 4); and 

• it is not in traffic mode for transmission or reception on this channel (see note 5). 

NOTE 3: At the end of a random access attempt (i.e. when the MS receives a response from the BS or abandons the 
random access attempt), the MS may check whether it may enter napping mode based on the other 
criteria. For example, if the BS response message gives immediate napping permission, the response 
message makes that address currently eligible for napping; if the BS response message does not give 
immediate napping permission, that address is currently ineligible for napping. 

NOTE 4: At the end of a reconstruction (i.e. when the MS receives the MAC-END PDU or the reconstruction 
procedure fails), the MS may check whether it may enter napping mode based on the other criteria. 

NOTE 5: The MS may check whether it may enter napping mode based on the other criteria when it goes out of 
traffic mode. 

NOTE 6: If the MS is in napping mode on a channel assigned for a circuit mode call, and it receives an 

ACCESS-ASSIGN PDU in frames 1 to 17 in a slot appropriate to the downlink assigned channel, 
containing Header t- OO2 and containing the correct downlink traffic usage marker for this MS, the MS 
may choose to revert to full reception mode temporarily if it wishes to use "N.213 permission method" 
criterion for entering traffic mode for reception of traffic (see clause 23.8.2.3.2). 

23.4.8.3 MS reception requirements 

23.4.8.3.1 Generation of napping reception pattern 

The "napping reception timeslots" element is a four-bit bit map, even when the allocated channel is a one-slot, two-slot 
or three-slot channel. In order to allow the BS flexibility to instruct the MS that the current napping information may be 
used on another allocated channel (for example, in the case of a channel replacement), the "napping reception timeslots" 
bit map may contain a bit set to 1 for timeslot(s) that are not appropriate to the downlink assigned channel as defined by 
element "timeslot assigned". This does not indicate that the MS is required to receive those slots. 
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Therefore, when the MS moves to a assigned channel on which use of the napping procedure is permitted (i.e. when it 
obeys an augmented channel allocation with "napping status" element set to OI2 or IO2), the MS-MAC shall derive a 
"napping reception pattern" for that channel i.e. a four-bit timeslot bit map indicating the downlink slot or slots that the 
MS-MAC is required to receive in the napping reception frames when it is in napping mode. The MS-MAC shall derive 
the "napping reception pattern" from the "timeslot assigned" element for the assigned channel and from the appropriate 
"napping reception timeslots" element; the latter is: 

• for "napping status" = OI2, the "napping reception timeslots" element in the "napping information" element in 
the channel allocation; or 



• 



for "napping status" = IO2, the "napping reception timeslots" element appropriate on the channel on which the 
channel allocation was received. 



For each of the four bits in the "timeslot assigned" and "napping reception timeslots" bit maps: 

• if that bit is set to 1 in both the "timeslot assigned" and "napping reception timeslots" bit maps, then the 
MS-MAC shall set the corresponding bit in the "napping reception pattern" bit map to 1; 

• otherwise the MS-MAC shall set the corresponding bit in the "napping reception pattern" bit map to 0. 

If the resulting "napping reception pattern" is OOOO2 (i.e. no match between the "timeslot assigned" and "napping 
reception timeslots" bit maps), the MS-MAC shall set the "napping reception pattern" to the value of the "timeslot 
assigned" element. 

23.4.8.3.2 Reception requirements when MS is in napping mode 

When the MS -MAC is in napping mode on an assigned channel, it shall attempt to receive and decode at least the 
downlink slots indicated by the "napping reception pattern" in at least the TDMA frames indicated by the "napping 
reception frames" element for that assigned channel (within the constraints of the cell reselection procedures, and 
linearization and transmission requirements). If the MS is not able to attempt to receive and decode at least one of the 
downlink slots indicated by the "napping reception pattern" in a TDMA frame indicated by the "napping reception 
frames" element because of linearization or transmission requirements then, in that TDMA frame, the MS shall attempt 
to receive and decode any downlink slots of the assigned channel that it is capable of receiving. 

Additionally, when the MS -MAC is in napping mode on an assigned channel and: 

• MAC timer T.202 is running on this channel; and/or 

• MAC timer T.206 is running on this channel; and/or 

• the LLC has indicated (using the "LLC timer status" parameter in the TMC-CONFIGURE request primitive) 
that any of its timers measured in downlink signalling frames are currently running on this channel; 

the MS shall attempt to receive and decode at least the downlink slots indicated by the "napping reception pattern" in all 
TDMA frames (within the constraints of the cell reselection procedures, and linearization and transmission 
requirements). If the MS is not able to attempt to receive and decode at least one of the downlink slots indicated by the 
"napping reception pattern" in a TDMA frame because of linearization or transmission requirements then, in that 
TDMA frame, the MS shall attempt to receive and decode any downlink slots of the assigned channel that it is capable 
of receiving. 

NOTE 1: The LLC timers that are measured in downlink signalling frames are timers T.251, T.252, T.261, T.263 
and T.265; see annex A. 

NOTE 2: The procedure requiring reception in all TDMA frames (not just in the napping reception frames) when 
T.202 or T.206 or one of these LLC timers is running is defined so that the MS and BS should count the 
downlink signalling frames in the same way, even if the BS perceives that the MS may be napping when 
the MS is actually in full reception mode (for example, because another address is ineligible for napping 
or because the MS was not able to decode a PDU giving immediate napping permission). 

NOTE 3: In an implementation, the MS may choose to regard the "napping reception frames" as always requiring 
reception in all TDMA frames. This reduces the napping opportunities when the BS has permitted 
reception every two or three TDMA frames in napping mode, but would mean that the same procedure 
applies in napping mode irrespective of whether T.202 or T.206 or the LLC timers are running. 
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NOTE 4: The setting of the "reduced reception in frame 18 flag" for the assigned channel affects the reception 

requirements when the MS is in full reception mode. It does not affect the reception requirements when 
the MS is in napping mode. 

23.4.8.3.3 Reception requirements when MS is in full reception mode 

When the MS -MAC is in full reception mode on an assigned channel on which use of the napping procedure is 
permitted, the MS reception requirements may vary depending on the value of the "reduced reception in frame 18 flag" 
for that assigned channel. If the "reduced reception in frame 18 flag" was set to 1, the MS is usually permitted to use the 
"napping reception pattern" in frame 18 instead of receiving all downlink slots of the assigned channel (as indicated by 
the "timeslot assigned" element in the channel allocation). 

If the MS is in full reception mode on an assigned channel and is not in traffic mode for transmission or reception on 
this channel then: 

• the MS shall attempt to receive and decode all downlink slots of the assigned channel in frames 1 to 17 (within 
the constraints of the cell reselection procedures, and linearization and transmission requirements); 

• if the "reduced reception in frame 18 flag" was set to indicating that reduced reception in frame 18 is not 
permitted, or the MS-MAC is currently performing reconstruction on this channel of a downlink TM-SDU for 
any of its addresses or event labels, then the MS shall attempt to receive and decode all downlink slots of the 
assigned channel in frame 18 (within the constraints of the cell reselection procedures, and linearization and 
transmission requirements); 

• if the "reduced reception in frame 18 flag" was set to 1 indicating that reduced reception in frame 18 is 
permitted, and the MS-MAC is not currently performing reconstruction on this channel of a downlink 
TM-SDU for any of its addresses or event labels, then the MS shall attempt to receive and decode at least the 
downlink slots indicated by the "napping reception pattern" in frame 18 (within the constraints of the cell 
reselection procedures, and linearization and transmission requirements); if the MS is not able to attempt to 
receive and decode at least one of the downlink slots indicated by the "napping reception pattern" in a 
frame 18 because of linearization or transmission requirements then, in that frame 18, the MS shall attempt to 
receive and decode any downlink slots of the assigned channel that it is capable of receiving. 

If the MS is in traffic mode for transmission or reception on this channel, the requirements for reception of the downlink 
channel shall be as specified in clauses 23.3.1.3 and 23.3.1.4. 

23.4.8.4 MS use of napping status element 

When the MS moves to an assigned channel allocated with an augmented channel allocation, the "napping status" 
element indicates whether use of the napping procedure is permitted on the allocated channel. If "napping status" = OO2 
(or for a non-augmented channel allocation), the MS shall assume that use of the napping procedure is not permitted on 
the allocated channel. If "napping status" = OI2 or IO2, the MS may assume that use of the napping procedure is 
permitted on the allocated channel. 

If "napping status" = OI2, the appropriate napping information for use on the allocated channel is included in the 
channel allocation. 

Alternatively, the "napping status" element may be set to IO2, indicating that the MS may regard any napping 
information appropriate on the current channel (i.e. the channel on which the channel allocation was received) as being 
appropriate also on the allocated channel. Thus: 

• the MS may regard the "napping reception frames", "napping timer T.226" and "reduced reception in 
frame 18 flag" from the current napping information as being appropriate on the allocated channel; 

• the MS may also regard the "napping reception timeslots" from the current napping information as being 
appropriate on the allocated channel, in which case it shall use that information, together with the "timeslot 
assigned" element for the allocated channel, in order to derive the "napping reception pattern" for the allocated 
channel (see clause 23.4.8.3.1). 
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23.4.8.5 Independent allocation of uplink and downlink 

When a channel is allocated, if the "up/downlink assigned" or "up/downlink assigned for augmented channel allocation" 
element in the channel allocation indicates that the MS has only been allocated either the uplink or the downlink then 
(as specified in clause 23.3.4), for the application of the general procedures for transmission and reception of signalling 
messages, the control channel shall be assumed to occupy any control slots on both the uplink and downlink directions, 
as indicated by the "timeslot assigned" element in the channel allocation. This applies also to the napping procedure if 
the MS has been assigned only one direction, so the normal napping procedure applies. 

It is possible that the MS may receive concurrent independent channel allocations for the uplink and downlink of the 
same channel (e.g. both on the MS's individual address, or one on the MS's individual address and the other on one of 
the MS's group addresses): 

• If the napping information is the same for both directions, the MS may assume that the normal napping 
procedure applies. 

• If the napping information is different for the two directions, the MS shall regard the two sets of napping 
procedures as applying independently. Then: 

The MS shall attempt to receive and decode downlink slots of the assigned channel if required by either 
set of napping procedures (within the constraints of the cell reselection procedures, and linearization and 
transmission requirements). 

If the BS sends a "replace" or "replace + CSS channel" channel allocation on that channel, it should 
include a higher layer message, thus enabling the MS to deduce which of the current channel allocations 
is being replaced (see clause 23.5.4.2.3) - and thereby also enabling the MS to deduce which set of 
napping information applies on the allocated channel if "napping status" = IO2; this applies also for a 
"quit command". If the MS is unable to deduce which set of napping information applies on the allocated 
channel then it shall regard both sets of napping information as still applying on the current channel and 
shall regard napping as not being permitted on the allocated channel. 

If the BS sends an "add" channel allocation on that channel with "napping status" = IO2, the MS shall 
regard both sets of napping information as applying on the allocated channel. 

Alternatively the MS may regard napping as not being applicable. 

23.4.8.6 BS procedures for supporting MS napping 

If the BS supports the use of the napping procedure by MSs, it may include napping information in channel allocations 
sent to MSs that support the augmented channel allocation (as indicated in the "extended capabilities" element in the 
U-LOCATION UPDATE DEMAND PDU). 

NOTE 1: MSs that support D8PSK and/or QAM operation need to support the augmented channel allocation. It is 
optional whether an MS which only supports 7i/4-DQPSK operation supports the augmented channel 
allocation. The BS designer should note that an MS which does not support the augmented channel 
allocation will discard augmented channel allocations addressed to itself. 

The napping procedure is intended principally for multi-slot channels. However it may be used to enable some battery 
economy on a single-slot channel if the "napping reception frames" element specifies reception in every two or three 
TDM A frames. 

The methods used by the BS for choosing the napping information are outside the scope of the present document. The 
choice may be based on a compromise between allowing flexibility of scheduling of the downlink channel and giving 
opportunities for MS neighbour cell monitoring, sectored channel monitoring, main carrier monitoring, background 
scanning and/or battery economy. The choice may also depend on whether the BS makes use of the immediate napping 
permission facility, since the same napping information applies during short gaps in transmission (using the immediate 
napping permission facility) and during longer gaps (e.g. based on inactivity timer T.226). 

NOTE 2: The "immediate napping permission flag" is included in MAC-RESOURCE, MAC -END and 

MAC-D-BLCK PDUs sent using 71/8-D8PSK or QAM modulation, and in MAC-D-BLCK PDUs sent 
using 7I/4-DQPSK modulation; however, it is not included in MAC-RESOURCE and MAC -END PDUs 
sent using 7i/4-DQPSK modulation. Therefore use of the immediate napping permission facility is 
restricted on 3i/4-DQPSK channels and when using 3i/4-DQPSK modulation on D8PSK channels. 
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If the BS makes use of the immediate napping permission facility, the methods used by the BS for choosing when to 
give immediate napping permission are outside the scope of the present document. The methods of use may depend on 
the type of data being sent by the BS or the MS. For example: 

• When the BS is sending background class data to an MS, the BS may choose usually to set the "immediate 
napping permission flag" to until the end of the data - except when there are intervals when the BS knows 
that it will be transmitting to other MSs for the next few slots or frames. Thus the MS may be required to 
receive most of the downlink assigned slots during the data transfer. The MS returns to napping mode at the 
end of the data, either immediately or after time T.226, depending on the setting of the "immediate napping 
permission flag". 

• When the MS is sending background class data to the BS, the BS may choose whether to set the "immediate 
napping permission flag" to or 1 - depending on whether it needs to have flexibility to send 
acknowledgements and slot grants in any slot of the downlink assigned channel. 

• When the BS is sending data involving periodic transmissions of short packets (such as real-time class data or 
telemetry class data), the BS may choose to set the "immediate napping permission flag" to 1 in most or all 
downlink MAC PDUs sent to the MS. (For packets that require more than one slot, the flag would be set to 1 
only in the last of the slots sent to this MS.) 

• When the MS is sending data involving periodic transmissions of short packets, the BS may choose to set the 
"immediate napping permission flag" to 1 in most or all downlink MAC PDUs sent to the MS e.g. the 
downlink MAC PDUs containing the slot grants and/or link adaptation feedback messages. 

If the BS sends a channel allocation on an assigned channel, allocating another assigned channel, it may set the 
"napping status" element to OO2 to indicate that use of the napping procedure is not permitted on the allocated channel, 
or it may set the "napping status" element to OI2 and provide napping information for use on the allocated channel. 
Alternatively it may set the "napping status" element to IO2 to indicate that current napping information may be used on 
the allocated channel; for example, this may be used if the BS wishes MSs to retain their current individual napping 
information after a channel replacement on a group address - particularly if performing the channel replacement using 
the predefined broadcast group address. (The BS should choose an appropriate method if it wishes to send a channel 
replacement on a 7i/4-DQPSK channel using a group address if some MSs in the group support the augmented channel 
allocation and other MSs do not - for example, sending the augmented channel allocation first.) 

23.4.9 Link adaptation on D8PSK or QAM ciiannel 
23.4.9.1 General 

On a D8PSK channel, signalling and data messages may generally be sent using either 7i/4-DQPSK or 71/8-D8PSK 

bursts: 

• for downlink transmissions in the assigned slots in frames 1 to 17, and in the assigned slots in frame 18 for 
which (MN + TN) mod 4 = 2 or 4, the BS shall choose whether to use a 7i/4-DQPSK or 71/8-D8PSK burst on a 
slot-by-slot basis; 

• for reserved slots and subslots on the uplink, the transmitting MS shall choose whether to use a 7t/4-DQPSK or 
71/8-D8PSK burst in each slot or subslot. 

On a QAM channel, signalUng and data messages may generally be sent using any valid combination of modulation and 
coding rate: 

• for downlink transmissions, the BS shall choose which modulation level and coding rate to use for the 
SCH-Q/D on a slot-by-slot basis; 

• for reserved uplink slots and subslots on the uplink, the transmitting MS shall choose which modulation level 
and coding rate to use for the SCH-Q/U in each slot or SCH-Q/HU in each subslot - subject to the maximum 
uplink modulation level permitted by the BS. 
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In the link adaptation algorithm, the MAC may evaluate the current state of the link; then, when sending a TM-SDU, 
the MAC adaptively selects the appropriate modulation level (and coding rate for QAM) to use, based on: 

a) the link conditions; and 

b) the data category parameter in the TMA-UNITDATA request primitive. 

NOTE 1: It is not expected that the MS or BS would attempt to follow changes in the link conditions over a period 
shorter than about half a second. 

Alternatively, the MAC may use a predefined choice of modulation levels (and coding rates for QAM) for each of the 
data categories (or for some of the data categories). Then, when sending a TM-SDU, the MAC selects the appropriate 
modulation level (and coding rate for QAM) based solely on the data category parameter in the TMA-UNITDATA 
request primitive. 

The data category parameter provides information about the type of data in the TM-SDU and the required reliability 
level for the transmission. The MS designer should choose an appropriate definition of the data category parameter for 
the chosen link adaptation algorithm. For example, the data category parameter may indicate whether the data is: 

background class data - reliability level 1 ; or 

background class data - reliability level 2; or 

background class data - reliability level 3; or 

telemetry class data - reliability level 1 ; or 

telemetry class data - reliability level 2; or 

telemetry class data - reliability level 3; or 

real-time class data; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 1; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 2; or 

non-classified data (i.e. TM-SDU does not contain packet data) - reliability level 3. 

NOTE 2: In this example of possible data categories, it is intended that reliability level 3 refers to better (i.e. higher) 
reliability than reliability level 2, and reliability level 2 refers to better (i.e. higher) reliability than 
reliability level 1. See also clause 22.3.1.10. 

NOTE 3: In this example of possible data categories, three reliability levels are used for background class data, 
telemetry class data and non-classified data. In an implementation, fewer than three reliability levels 
could be used if preferred. For instance, if preferred, two reliability levels could be used for background 
class data and/or telemetry class data and/or non-classified data. 

NOTE 4: The MAC uses both the data class and the reliability level when it selects the appropriate modulation 

level (and coding rate for QAM). For example, the appropriate modulation level (and/or coding rate for 
QAM) for "telemetry class data - reliability level 1" may be different from that for "background class data 
- reliability level 1 " . 

The data category parameter is also used in the buffering process between the LLC and the MAC. It is used in the 
DATA-IN -BUFFER signal, so that the MS-MAC can estimate the reservation requirement from the amount of data in 
the LLC buffer per data category; see clause 23.5.2.1. It is also used in the MAC-READY signal; see clause 23.1.2.1.2. 

Two layer 2 signalling messages may be used in the link adaptation process: 

• the L2-LINK-FEEDBACK-CONTROL message may be used by the BS either: 

to request link adaptation feedback from the MS on a D8PSK or QAM channel; or 

to terminate link adaptation feedback from the MS; 
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• the L2-LINK-FEEDBACK-INF0 message may be used by the BS or MS to send link adaptation feedback 
information on a D8PSK or QAM channel. 

The MAC sends and receives layer 2 signalling messages using the data transfer service provided by the LLC at the 
TLE-SAP; see clause 23.1.4. 

23.4.9.2 MS choice of bit rate 

23.4.9.2.1 General on MS choice of bit rate 

When on a D8PSK or QAM channel, the MS-MAC shall maintain assessments of the current appropriate bit rate for use 
for reserved access transmission for each of the data categories i.e. 

• on a D8PSK channel, the appropriate modulation (7i/4-DQPSK or ti/S-DSPSK) for each data category; or 

• on a QAM channel, the appropriate modulation level and coding rate for each data category. 

These assessments are used when the MS-MAC has a reserved slot (or subslot) individually granted to it by the BS, as 
described in clause 23.1.2.1.3. As indicated below, the assessments of the appropriate bit rate for each of the data 
categories may be adaptive estimates, varying with the current channel conditions, or may be predefined choices. 

The MS designer should choose suitable criteria for the MS -MAC to decide on the current appropriate bit rate for each 
of the data categories. The criteria may be based on various types of information, including the following: 

a) Any L2-LINK-FEEDBACK-INFO messages received from the BS. 

The feedback information may indicate the preferred bit rate for a specified data class; alternatively it may 
provide the BS's estimate of the E/No received on the uplink and (optionally) the BS's estimate of the channel 
model and speed; see clause 21. If the feedback information indicates a preferred bit rate for background class 
data or telemetry class data, the MS should regard this as applying to the lowest reliability level for that class 
of data (and the MS should regard lower (or equal) bit rates as applying to the other reliability levels for that 
class of data). 

b) Link performance information in the TMC-CONFIGURE request primitive. 

This parameter may be provided by the LLC, indicating information about the current advanced link 
performance. For example, the LLC may provide information derived from the acknowledgement bit maps in 
received AL-ACK, AL-RNR, AL-X-ACK and AL-X-RNR PDUs. 

NOTE 1 : The method for derivation of this link performance information is outside the scope of the present 
document. However the following points may be noted: 

■ If multiple advanced link segments are sent in a single slot, then those segments will all either be 
successfully received or fail together. This may need to be taken into account if the MS is using a 
Unk adaptation algorithm based on estimating slot error rates. 

■ If the MS has used a mixture of different bit rates to send the segments, it may need to keep a 
record of the bit rate used to send those segments, for comparison with the information derived 
from the acknowledgement bit maps - if the MS is using a link adaptation algorithm based on 
estimating slot error rates at particular bit rate(s). 

■ If the MS's link adaptation algorithm gives more weighting to the success or failure of segments 
that were sent recently, the MS may need to keep a record of when segments were sent, for 
comparison with the information derived from the acknowledgement bit maps. 

c) Measurements of the downlink channel, such as: 

1) measurements of slot error rates on the downlink channel for different bit rates; and/or 

2) other measurements of the downlink channel e.g. E/Nq or RSSI or symbol quality measurements. 

Use of this information, together with knowledge of the BS link imbalance and an MS correction factor (see 
clause 21.5.2a), may enable the MS to make an approximate estimate of the uplink slot error rates. 
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NOTE 2: When making measurements of the downlink channel, the MS may use information from any downlink 
slots on the channel, not only those slots containing information addressed to itself In case cl): 

■ on a D8PSK channel, the MS determines whether a downlink slot contains a 7i/4-DQPSK normal 
downlink burst or a 31/8-D8PSK normal downlink burst by inspecting the training sequence; 

on a QAM channel, the MS first attempts to decode the QAM-SLOTINFO PDU in the SICH-Q/D 
in order to determine the bit rate used in the remainder of the slot; it may record the decode failure 
rate for any slots on the downlink channel for which it can decode the QAM-SLOTINFO PDU. 

d) Choice of predefined bit rates for each of the data categories. 

This choice of predefined bit rates may be made by the MS designer. 

Predefined bit rates may be used in different ways; for example: 

1) predefined bit rates may be used temporarily as a default in the absence of preferred information; 

2) alternatively, the MS designer may choose to use suitable predefined bit rates for each of the data 
categories in general (or for some of the data categories), in order to provide a simple link adaptation 
algorithm; see also clause 23.4.9.2.2. 

The information used may depend on the data category; for example, use of method b) is not appropriate when the MS 
is sending real-time class data. Also, use of method b) may not be appropriate for infrequent telemetry class data. 

The information used may also depend on whether the MS is starting to send data (or a significant time has elapsed 
since the MS last transmitted data) or whether the MS has been transmitting data for some time. For example: 

• use of method b) is not appropriate when the MS is starting to send advanced link data or if a significant time 
has elapsed since the MS last transmitted advanced link data; 

• when the MS is starting to send advanced link data or if a significant time has elapsed since the MS last 
transmitted advanced link data, the MS could use method c) or use a predefined choice of bit rate; 

• when the MS is starting to send real-time data, the MS could use method c) or use a predefined bit rate. 

NOTE 3: If the MS is not frequency full duplex and is operating on a multi-slot channel, it may not be able to 
receive the downlink assigned channel during the elapse time corresponding to one granted capacity 
allocation, depending on the MS's fast switching capability and the timeslots belonging to the assigned 
channel. (For multiple slot granting, the MS can receive the downlink assigned channel between each 
instance of capacity allocation for appropriate values of the granting delay.) If the MS cannot receive the 
downlink assigned channel during the elapse time corresponding to a capacity allocation, it cannot receive 
L2-FEEDBACK-INFO messages or acknowledgement bit maps from the BS, or make measurements of 
the downlink assigned channel, during the elapse time corresponding to that capacity allocation. In this 
case, the BS may choose to limit the size of each instance of the capacity allocation. This may apply 
particularly when the BS perceives that the quality of the link is currently variable such that the MS may 
wish to adapt its bit rate more frequently than the maximum length of capacity allocation. 

If the MS maintains an adaptive estimate of the appropriate bit rate for each of the data categories (varying with the 
current channel conditions) then: 

• In the absence of feedback information from the BS indicating a preferred bit rate, the MS may use the chosen 
information in order to choose a bit rate such that the actual uplink slot error rate for each data category is 
intended to lie within a target range. The target range would generally be different for the different data 
categories. The choice involves a trade-off between throughput and reliability of a single transmission: if the 
uplink slot error rate exceeds the maximum acceptable then a lower bit rate may be appropriate in order to 
achieve more reliability; whereas, if the uplink slot error rate is less than the minimum in the target range then 
a higher bit rate may be appropriate in order to achieve higher throughput. 
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• When choosing an algorithm for making an adaptive estimate of the appropriate bit rate: 

it is expected that the MS designer may choose an algorithm which allows relatively high slot error rates 
to be used for "background class data - reliability level 1", thereby enabling choice of higher bit rates and 
therefore higher throughput, and relying on the advanced link retransmission protocol in the case of 
failed segments; then more moderate slot error rates may apply for "background class data - reliability 
level 2"; and lower slot error rates should apply for "background class data - reliability level 3" (which 
may be used when the maximum number of segment retransmissions will soon be exceeded); 

it is expected that the MS designer would choose an algorithm with relatively low slot error rates for 
"real-time class data"; 

it is expected that the MS designer would choose an algorithm with relatively low slot error rates for 
"non-classified data - reliability level 3"; 

it is expected that the MS designer may choose an algorithm which allows intermediate slot error rates to 
be used for "telemetry class data - reliability level 1" (i.e. lower than for "background class data - 
reliability level 1"); then reduced slot error rates may apply for "telemetry class data - reliability level 2"; 
and lower slot error rates should apply for "telemetry class data - reliability level 3" (which may be used 
when the maximum number of segment retransmissions will soon be exceeded). 

NOTE 4: Use of a predefined choice of bit rates may be more appropriate for infrequent telemetry class data. 

NOTE 5: If fewer than three reliability levels are used then appropriate target ranges for slot error rates may still 

apply. For example, if using two reliability levels for background class data, the MS designer may choose 
an algorithm which allows relatively high slot error rates to be used for "background class data - 
reliability level 1"; then lower slot error rates should apply for "background class data - reliability level 2" 
(which is used when the maximum number of segment retransmissions will soon be exceeded). 

The following additional points may be noted relating to transmission on a QAM channel: 

• when the MS transmits in a slot or subslot, it shall not exceed the maximum uplink QAM modulation level 
permitted by the BS; 

• if the MS is capable of using 64-QAM, and the BS permits use of 64-QAM on the upUnk, the MS should use 
64-QAM in preference to using 16-QAM with coding rate r = 1. 

23.4.9.2.2 Suggested predefined bit rates for background class and telemetry class data 

23.4.9.2.2.1 General 

Clause 23.4.9.2.1 gives general information on MS choice of bit rate. The MS designer should choose suitable criteria 
for the MS to decide on the current appropriate bit rate for each of the data categories. The assessments of the 
appropriate bit rate for each of the data categories may be adaptive estimates, varying with the current channel 
conditions, or may be predefined choices. 

Clauses 23.4.9.2.2.2 and 23.4.9.2.2.3 suggest possible choices of predefined bit rates for background class data and 
telemetry class data. The MS should use appropriate bit rates for each of the data categories for background class data 
and telemetry class data to provide performance equal to or better than use of these suggested predefined bit rates. 

NOTE: The suggested predefined bit rates in clauses 23.4.9.2.2.2 and 23.4.9.2.2.3 provide a simple link 

adaptation algorithm for background class data and telemetry class data. It is expected that a simple link 
adaptation algorithm using a predefined choice of bit rates may be the most appropriate for telemetry 
class data because link performance information may be out-of-date. However, it is expected that, at least 
for background class data, MS designers may prefer to use adaptive estimates of the appropriate bit rates 
in such a way as to provide better performance. 
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23.4.9.2.2.2 Suggested predefined bit rates on D8PSK cinannel 

For background class data and telemetry class data, if the maximum number of segment retransmissions (LLC 
parameter N.274) is at least three, the MS should use appropriate bit rates for each of the data categories to provide 
performance equal to or better than use of the following predefined choices: 

• one transmission of each segment at reliability level 1, using 71/8-D8PSK modulation; 

• if retransmission of a segment is needed: 

one transmission of that segment at reliability level 2, using 71/8-D8PSK modulation; 

• then, if retransmission of the segment is still needed: 

further transmission(s) of that segment at reliability level 3, using 3i/4-DQPSK modulation. 

As indicated in clause 22.3.1.10, the maximum number of segment transmissions using reliability level 1 (and/or 
reliability level 2) may depend on the maximum number of segment retransmissions N.274 for that advanced link. 

Also, in an implementation, there may be some variations according to the current channel conditions (without 
necessarily using full adaptive estimates); for example: 

a) the maximum number of segment transmissions using reliability level 1 (and/or reliability level 2) may vary 
according to the current channel conditions, based on information provided by the MAC to the LLC; 

b) when appropriate, the MS may revert to using fewer than three reliability levels; 

c) when the channel conditions are perceived as poor, the MS could decide adaptively not to attempt any segment 
transmissions using 31/8-D8PSK modulation until the channel conditions are perceived to have improved. 

NOTE: On a D8PSK channel, fragmentation is generally needed when a segment first sent using 71/8-D8PSK 

modulation is retransmitted using 7i/4-DQPSK modulation (because the segment is cut to match the size 
of a 71/8-D8PSK MAC block). This impairs the performance of the 7i/4-DQPSK retransmission compared 
with the performance if the segment had been first sent using 7i/4-DQPSK modulation (in which case the 
segment would have been cut to match the size of a 7i/4-DQPSK MAC block). Therefore, as indicated in 
point c), the MS may choose not to attempt any segment transmissions using 71/8-D8PSK modulation 
when the MS perceives that a 71/8-D8PSK transmission would be unlikely to be successfully received. 

23.4.9.2.2.3 Suggested predefined bit rates on QAM cinannel 

For background class data and telemetry class data, if the maximum number of segment retransmissions (LLC 
parameter N.274) is at least three, the MS should use appropriate bit rates for each of the data categories to provide 
performance equal to or better than use of the following predefined choices: 

• one transmission of each segment at reliability level 1 : 

using 64-QAM rate = % if the BS permits use of 64-QAM on the uplink; else 
using 16-QAM rate = Vi; 

• if retransmission of a segment is needed: 

one transmission of that segment at reliability level 2, using 16-QAM rate = Vr, 

• then, if retransmission of the segment is still needed: 

further transmission(s) of that segment at reliability level 3, using 4-QAM rate = Vi. 

As indicated in clause 22.3.1.10, the maximum number of segment transmissions using reliability level 1 (and/or 
reliability level 2) may depend on the maximum number of segment retransmissions N.274 for that advanced link. 
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Also, in an implementation, there may be some variations according to the current channel conditions (without 
necessarily using full adaptive estimates); for example: 

a) the maximum number of segment transmissions using reliability level 1 (and/or reliability level 2) may vary 
according to the current channel conditions, based on information provided by the MAC to the LLC; 

b) when appropriate, the MS may revert to using fewer than three reliability levels; 

c) when the channel conditions are perceived as poor, the MS could decide adaptively not to attempt any segment 
transmissions using 64-QAM until the channel conditions are perceived to have improved. 

NOTE: Fragmentation is not generally needed when a segment first sent using 64-QAM is retransmitted using 
16-QAM or 4-QAM, or when a segment first sent using 16-QAM is retransmitted using 4-QAM. 

23.4.9.3 BS choice of bit rate 

The BS designer should choose suitable criteria for the MAC in the BS to decide on the appropriate bit rate in each 
downlink slot. The criteria for the BS to decide on an appropriate bit rate to use when sending data of a particular 
category to an MS may be based on various types of information, including the following: 

a) any L2-LINK-FEEDBACK-INFO messages received from that MS; and/or 

b) link performance information relating to current advanced link performance (such as information derived from 
the acknowledgement bit maps in received AL-ACK, AL-RNR, AL-X-ACK and AL-X-RNR PDUs); and/or 

c) measurements of the uplink slots and subslots used by that MS; and/or 

d) choice of predefined bit rates for each of the data categories (or for some of the data categories), for example: 

for temporary use as a default in the absence of preferred information; or 

for use in general, in order to provide a simple link adaptation algorithm. 

The information used may depend on whether the BS is starting to send data to the MS (or a significant time has 
elapsed since the BS last transmitted data to the MS) or whether the BS has been transmitting data to the MS for some 
time. 

The BS may include signalling or data messages for more than one MS within one downlink slot. The BS should take 
account of the appropriate bit rate for transmission to each MS when deciding which messages to associate within a slot 
and when choosing the bit rate to use in the slot. 

NOTE: It is recommended that PDUs containing slot grants are sent using a high reliability. 

The following additional points may be noted relating to transmission on a QAM channel: 

• the BS should not exceed the maximum QAM modulation level supported by that MS for reception; 

• if the BS and MS are both capable of using 64-QAM, the BS should use 64-QAM in preference to using 
16-QAM with coding rate r = 1. 

23.4.9.4 Link adaptation feedback control by BS 

The BS may send the L2-LINK-FEEDBACK-CONTROL message either: 

• to request link adaptation feedback from the MS on a D8PSK or QAM channel; or 

• to terminate link adaptation feedback from the MS. 

The request for link adaptation feedback may solicit a single feedback message from the MS, or it may also invite 
feedback from the MS, following a change in channel conditions, for a specified feedback duration. When the BS sends 
a request for link adaptation feedback, it may include a slot grant (e.g. granting a subslot) for the solicited feedback 
message from the MS. 
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The request for link adaptation feedback indicates a preferred channel metric type (and the appropriate data class in the 
case of a request for bit rate feedback). However the BS should note that the MS may send feedback with a different 
channel metric type if it does not support the preferred channel metric type. 

It is recommended that the BS requests link adaptation feedback during transmission of real-time class data to an 
individual MS if the BS wishes to use link adaptation for that data. 

The BS may request link adaptation feedback during transmission of telemetry class data and/or background class data. 

The termination of link adaptation feedback message indicates the channel metric type (and the data class in the case of 
bit rate feedback) to which the termination applies. 

23.4.9.5 Link adaptation feedback by MS 
23.4.9.5.1 Sending link adaptation feedback 

On receipt of an L2-LINK-FEEDBACK-CONTROL message (delivered by the LLC in a TLE-UNITDATA indication 
primitive), the MS-MAC shall inspect the "link feedback control type" element. 

If the "link feedback control type" element is set to OOO2, indicating a request for feedback, the MS-MAC shall send an 
L2-LINK-FEEDBACK-INFO message. The L2-LINK-FEEDBACK-CONTROL message indicates the preferred 
channel metric type for the feedback (and the appropriate data class in the case of a request for bit rate feedback). If the 
MS supports the preferred channel metric type, it shall send the information corresponding to that channel metric type 
(and that data class in the case of bit rate feedback) in the L2-LINK-FEEDBACK-INFO message; otherwise it shall 
send information corresponding to a channel metric type that it supports. 

If the L2-LINK-FEEDB ACK-CONTROL feedback request message contains "feedback duration T.230" element set to 
OOOOOO2, the MS-MAC shall not send any further L2-LINK-FEEDBACK-INFO messages relating to this feedback 
request. 

If the L2-LINK-FEEDB ACK-CONTROL feedback request message contains "feedback duration T.230" element not 
equal to OOOOOO2, the MS-MAC may send further L2-LINK-FEEDBACK-INFO messages relating to this feedback 
request (designated "unsolicited" feedback messages) - when there has been a significant change in the perceived 
channel conditions and within the T.23 1 constraints defined below - until either: 

a) the MS-MAC receives a further L2 -LINK-FEEDBACK-CONTROL feedback request message containing the 
same channel metric type (and data class in the case of a request for bit rate feedback); or 

b) the MS-MAC receives an L2-LINK-FEEDB ACK-CONTROL feedback termination message containing the 
same channel metric type (and data class in the case of bit rate feedback) as in the 
L2-LINK-FEEDBACK-CONTROL feedback request message; or 

c) a time T.230 has elapsed since receipt of the L2-LINK-FEEDBACK-CONTROL feedback request message; or 

d) the MS leaves the current channel, unless the MS is leaving the channel as a result of obeying an augmented 
channel allocation within the current cell and with: 

i) "allocation type" element set to OO2 (Replace) or II2 (Replace + CSS channel); and 

ii) "modulation mode of allocated channel" element indicating that the allocated channel is a D8PSK or 
QAM channel. 

NOTE 1 : If the MS leaves the current channel as a result of obeying an augmented channel allocation within the 
current cell and satisfying criteria i) and ii), it may send further L2-LINK-FEEDBACK-INFO messages 
on the allocated channel (when there has been a significant change in the perceived channel conditions 
and within the T.231 constraints defined below) until one of criteria a), b), c) or d) applies. 

In case a), the MS shall process the L2-LINK-FEEDB ACK-CONTROL feedback request message as described above 
(responding with an L2-LINK-FEEDBACK-INFO message and then, if the "feedback duration T.230" element is not 
OOOOOO2, optionally sending further L2-LINK-FEEDBACK-INFO messages - subject to the constraints below). 
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During the time when unsolicited feedback is permitted: 



1) the MS-MAC shall not send an L2-LINK-FEEDBACK-INF0 message relating to this feedback request unless 
the minimum time interval T.231 has elapsed since the MS-MAC last sent an L2-LINK-FEEDBACK-INFO 
message relating to this feedback request; 

2) the MS-MAC should send an L2-LINK-FEEDBACK-INFO message if: 

there has been a significant change in the perceived channel conditions since the last feedback relating to 
this feedback request, such as a change in the preferred bit rate for this data class or a significant change 
in the Ej/Nq feedback information; and 

the minimum time interval T.231 has elapsed since the MS-MAC last sent an 
L2-LINK-FEEDB ACK-INFO message relating to this feedback request; 

3) the MS-MAC may send an L2-LINK-FEEDBACK-INFO message if: 

there has been a significant change in the perceived channel conditions since the last feedback relating to 
this feedback request sent either as the immediate response to the L2-LINK-FEEDBACK-CONTROL 
feedback request message or by successful random access; and 

the minimum time interval T.231 has elapsed since the MS-MAC last sent an 
L2-LINK-FEEDB ACK-INFO message relating to this feedback request; 

however, the MS-MAC shall not send the same or similar information more than a total of N.231 times. 

NOTE 2: If a feedback message was sent as the immediate response to a feedback request message, it is the BS's 
responsibility to send the feedback request message again if the response was not received. 

NOTE 3: If a feedback message was successfully sent by random access, the MS-MAC can deduce that the 
message was received by the BS. 

NOTE 4: If a feedback message indicating a significant change in the perceived channel conditions was sent by 
reserved access, and not as the immediate response to a feedback request message, or if the transfer 
failed, the MS-MAC may send another feedback message after expiry of timer T.231 (and possibly again 
after the next expiry of timer T.23 1 if the feedback message was again sent by reserved access) - within 
the limit defined by N.231; see point 3) above. This may apply particularly if the number of repetitions of 
the layer 2 signalling message was 0. However, the MS-MAC should not continually send the same 
information after each expiry of timer T.23 1 unless there is another significant change in the perceived 
channel conditions. Also, if the number of repetitions of the layer 2 signalling message was not 0, the 
MS -MAC should reduce the value of N.231 accordingly 

The MS may receive L2-LINK-FEEDBACK-CONTROL feedback request messages from the BS inviting unsolicited 
feedback messages relating to different channel metric types or different data class linkage. Then the above procedures 
for unsolicited feedback messages generally apply independently to each of the feedback request messages. However, if 
the MS is unable to support the preferred channel metric type and so sends information corresponding to the same 
channel metric type (and data class) in response to more than one feedback request then, when there is a significant 
change in the perceived channel conditions, the MS should only send the L2-LINK-FEEDBACK-INFO message 
according to the procedures for one of those feedback requests (e.g. when first permitted by one of the T.23 1 timers). 

When the MS-MAC sends an L2-LINK-FEEDB ACK-INFO message, it shall issue the message to the LLC in a 
TLE-UNITDATA request primitive. The MS-MAC should set PDU priority level = 6 in the request primitive. When the 
message is sent as the immediate response to an L2-LINK-FEEDBACK-CONTROL feedback request, the number of 
repetitions of the layer 2 signalling message shall be set to 0. For an unsolicited feedback message, it is recommended 
that the number of repetitions of the layer 2 signalling message is normally set to 0. 

If the MS-MAC sends an L2-LINK-FEEDB ACK-INFO message, and there is a significant change in the perceived 
channel conditions before the MS-MAC receives a TLE-REPORT indication primitive reporting completion of the 
transfer (either successful or failed transfer), the MS-MAC may cancel the ongoing transfer using the TLE-CANCEL 
request primitive and then send a revised L2-LINK-FEEDB ACK-INFO message. 
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23.4.9.5.2 MS feedback information 

When the MS-MAC sends an L2-LINK-FEEDBACK-INFO message, as defined in clause 23.4.9.5.1, it may indicate: 

• the preferred bit rate for reception of data for a specified data class; or 

• the MS's estimate of the E/No received on the downlink and (optionally) the MS's estimate of the channel 
model and speed. 

If the feedback information indicates a preferred bit rate for background class data or telemetry class data, this refers to 
the preferred bit rate for the lowest reliability level for that class of data. 

The MS designer should choose suitable methods for the MS to derive the preferred bit rate or to estimate the Eg/No 
received on the downlink and the channel model and speed. 

In order to derive or estimate this information, the MS needs to make measurements of the downlink channel, such as: 

1) measurements of slot error rates on the downlink channel for different bit rates; and/or 

2) other measurements of the downlink channel e.g. E^/Nq or RSSI or symbol quality measurements. 

NOTE: When making measurements of the downlink channel, the MS may use information from any downlink 
slots on the channel, not only those slots containing information addressed to itself. 

If the MS indicates the preferred bit rate for reception of data for a specified data class, it may use the measurements in 
order to choose that preferred bit rate such that the actual downlink slot error rate for the data is intended to lie within a 
target range. The target range may be different for the different data classes, since it involves a trade-off between 
throughput and reliability of a single transmission; for example, when choosing the preferred bit rate: 

• for background class data, the MS may select a preferred bit rate corresponding to a relatively high slot error 
rate, thereby enabling a higher bit rate and therefore higher throughput (relying on the advanced link 
retransmission protocol in the case of failed segments); 

• for real-time class data, the MS may select a preferred bit rate corresponding to a relatively low slot error rate; 

• for telemetry class data, an intermediate choice may be appropriate. 

On a QAM channel, if the MS indicates the preferred bit rate, the MS shall not indicate a QAM modulation level 
exceeding the maximum uplink QAM modulation level permitted by the BS. If the BS does not support transmission at 
the indicated QAM modulation level, it may use a lower modulation level that it supports (with an appropriate coding 
rate). Similarly, if the indicated coding rate is coding rate r = 1, and the BS does not support transmission using coding 
rate r = 1, the BS should use a coding rate that it supports. 

23.4.9.6 Link adaptation feedback by BS 

The BS may send the L2-LINK-FEEDBACK-INFO message to an MS at any time in order to provide link adaptation 
information. When the BS sends a link adaptation feedback message, it may include a slot grant for the MS's data. 

It is recommended that the BS sends link adaptation feedback when the MS is transmitting real-time class data if it 
wishes to enable the MS to use link adaptation for that data. 

The BS may send link adaptation feedback when the MS is transmitting background class data and/or telemetry class 
data. (This may not be useful for infrequent uplink telemetry class data.) 

The feedback information may indicate the preferred bit rate for a specified data class; alternatively it may provide the 
BS's estimate of the E^/No received on the uplink and (optionally) the BS's estimate of the channel model and speed. 

The BS designer should choose suitable methods for the BS to derive the preferred bit rate or to estimate the Ej/Nq 
received on the uplink and the channel model and speed. 
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On a QAM channel, if the BS indicates the preferred bit rate, the BS shall not indicate a QAM modulation level 
exceeding the maximum QAM modulation level supported by that MS for reception. If the MS does not support 
transmission at the indicated QAM modulation level, it should use a lower modulation level that it supports (with an 
appropriate coding rate). Similarly, if the indicated coding rate is coding rate r = 1, and the MS does not support 
transmission using coding rate r = 1, the MS should use a coding rate that it supports. 

EXAMPLE: If the MS supports reception but not transmission using 64-QAM then: 

■ if the BS indicates 64-QAM rate = 1/2 as the preferred bit rate, the MS should use 
16-QAMrate= 1/2; 

■ if the BS indicates 64-QAM rate = 2/3 as the preferred bit rate, the MS may choose to use 
either 16-QAM rate = 1/2 or 16-QAM rate = 1; 

■ if the BS indicates 64-QAM rate = 1 as the preferred bit rate, the MS should use 
16-QAM rate = 1 if supported for transmission or else should use 16-QAM rate = 1/2. 

23.4.1 MAC aspects of assigned channel replacement on serving cell 
23.4.10.1 MS-MAC advice to MLE on assigned channel replacement 

The MLE in the MS may request the SwMI to replace an assigned channel on the serving cell; see clause 18. The 
criteria used by the MLE to decide whether to request assigned channel replacement may include use of information 
provided by the MS-MAC about whether the MS-MAC considers that: 

a) channel replacement is advisable (for example, if an RF bandwidth reduction or a change of sector may be 
advisable because reliability performance on the current channel may not be acceptable); or 

b) channel replacement may be beneficial (for example, because performance on the current channel is good and 
a bandwidth increase might have a beneficial effect on data throughput); or 

c) performance on the current channel is acceptable. 

When the MS -MAC provides this information to the MLE, it shall use a TMC-REPORT indication primitive. 

NOTE 1: The MLE also uses path loss parameters (CI, C2, C4 and C5) provided by the MS-MAC in its criteria for 
requesting assigned channel replacement. See clause 23.7 for the definition of the path loss parameters. 

The MS designer should choose suitable criteria for the MS-MAC to issue the TMC-REPORT indication primitive to 
provide information relating to assigned channel replacement. The criteria may be similar in principle to those used in 
link adaptation if the MS maintains an adaptive estimate of the appropriate bit rate for each of the data categories, 
varying with the current channel conditions (see clause 23.4.9.2), or when the MS sends a preferred bit rate for 
reception of data (see clause 23.4.9.5.2). However, in the case of assigned channel replacement, the criteria may be 
based on the most demanding data class for currently active PDP context(s) using the current channel; the information 
about the most demanding data class is provided to the MS-MAC using the TMC-CONFIGURE request primitive 
("data class activity information" parameter). 

NOTE 2: The real-time data class is more demanding than the telemetry data class, and the telemetry data class is 
more demanding than the background data class. The term "more demanding" here refers to reliability of 
transmission at the MAC layer. 
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For link adaptation, if the MS maintains an adaptive estimate of the appropriate bit rate for each of the data categories 
(varying with the current channel conditions), the MS may attempt to choose a bit rate such that the actual slot error rate 
for each data category or data class is intended to lie within a target range, where the target range may be different for 
the different data categories or data classes since it involves a trade-off between throughput and reliability of a single 
transmission; see clauses 23.4.9.2 and 23.4.9.5.2. Then, for example, for assigned channel replacement, the MS-MAC 
criteria for issuing the TMC-REPORT indication primitive might include the following or similar criteria: 

i) the MS-MAC might choose to indicate that channel replacement is advisable if the measured or estimated 

downlink slot error rate for the lowest modulation level, or the estimated uplink slot error rate (if available) for 
the lowest modulation level, exceeds either: 

the maximum acceptable slot error rate for the most demanding data class (see note 3); or 

the maximum acceptable slot error rate for non-classified data i.e. messages not containing packet data 
(see note 4); 

ii) the MS-MAC might choose to indicate that channel replacement may be beneficial if: 

the MS is capable of using a higher bandwidth channel; and 

the measured or estimated downlink slot error rate for the highest bit rate on the current channel and the 
estimated uplink slot error rate (if available) for the highest bit rate on the current channel are both less 
than the minimum slot error rate in the target range for the most demanding data class (see note 5 and 
note 6). 

NOTE 3: In case i), if the most demanding data class is the background data class or the telemetry data class, it may 
be preferable for the MS-MAC to advise channel replacement based on the maximum acceptable slot 
error rate for reliability level 3 rather than reliability level 1 or reliability level 2 (if using three reliability 
levels). If the most demanding data class is the real-time data class, it may be noted that SNDCP requires 
that the lost N-PDU probability for real-time class data is less than 2,5 % (see clause 28). 

NOTE 4: In case i), it may be preferable for the MS-MAC to advise channel replacement based on the maximum 
acceptable slot error rate for non-classified data with reliability level 3 rather than reliability level 1 or 
reliability level 2 (if using three reliability levels). 

NOTE 5: In case ii), when the MS-MAC is checking whether downlink and uplink slot error rates for the highest bit 
rate on the current channel are less than the minimum slot error rate in the target range for the most 
demanding data class, it may be preferable for the MS-MAC to exclude coding rate r = 1 (even if it 
supports transmission at coding rate r = 1). Then, for the purposes of the procedure in case ii), the 
MS-MAC would treat the highest bit rate on the current channel as being either 16-QAM rate = Vi or 
64-QAM rate = % as appropriate. 

NOTE 6: The MS-MAC's criteria for indicating that channel replacement may be beneficial may be affected by 
whether the MS is currently limiting its power as a result of the MS open loop power control procedure 
(see clause 23.4.4.2.2). 

23.4.1 0.2 Assigned channel replacement by BS 

When an MS is on an assigned channel, the BS may choose to move the MS to a different channel at any time (for 
example, from one QAM channel to another QAM channel with a different bandwidth) - based on its observations of 
the performance of the current channel and the MS's capabilities. It may also move the MS to a different channel as a 
result of any assigned channel replacement requests received from the MS at MLE level. 
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23.5 PDU transfer for signalling messages (TIVIA-SAP) 

23.5.1 Random access protocol 

23.5.1.1 Introduction 

The MS-MAC layer uses the random access protocol to initiate information transfer to the BS. The random access 
protocol is generally used for unsolicited MS messages, whereas messages solicited by the BS are sent using reserved 

access. 

The random access protocol is based on slotted ALOHA procedures, with a superimposed access framing structure. By 
a suitable choice of access parameters, it is possible for the BS to: 

• control the collision of access requests from different MSs; 

• minimize access delay and traffic loss for a particular traffic loading; 

• maintain peak throughput for a particular traffic loading; 

• avoid protocol instability; 

• dynamically restrict random access to different access priorities, and to selected groups and subscriber classes; 

• provide simultaneously, independent access grades of service for different groups and subscriber classes. 

The random access procedures defined in clauses 23.5.1.2, 23.5.1.3 and 23.5.1.4 are suitable for use on all types of 
control channel. 

23.5.1.2 Overview 

This clause provides a general overview of the random access protocol. The precise protocol definition is contained in 

clauses 23.5.1.3 and 23.5.1.4. 

23.5.1.2.1 General 

The BS may offer random access opportunities to different sets of MSs in turn by using "Access Codes". There is a 
maximum of four possible access codes (denoted A, B, C and D), and the BS marks each access opportunity with the 
appropriate access code. Alternatively, the BS may use a single access code. 

The binding of MSs to access codes is dynamic. The binding defines the minimum valid PDU priority for an access 
code. It may also restrict use of the access code to a set of subscriber classes, or to a group of MSs. An MS may use a 
subslot designated for a particular access code only if the PDU priority (as supplied by layer 3), and the subscriber class 
parameter or MS identity, conform to the current binding. 

For a particular access code, requests from MSs are invited within "access frames" consisting of a number of access 
opportunities (uplink subslots). 

The random access procedures are based on two types of PDU broadcast by the BS. The PDUs are: 

i) The ACCESS-DEFINE PDU 

This PDU is transmitted at intervals, how often being an operator option. It contains fairly slowly changing 
information about the random access parameters for an access code: 

the PDU priority and MS binding to the access code; 

a parameter (IMM) defining when immediate access is permitted for the first transmission; 

the waiting time (WT) before deciding to re-try; 

the permitted number of random access retries; 
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a frame-length multiplying factor; 

the uplink random access channel configuration. 

ii) The ACCESS-ASSIGN PDU 

This PDU: 

is transmitted in every downlink slot of a 7i/4-DQPSK or D8PSK channel, on the AACH; 

may be transmitted in downlink slots of a QAM channel (except slots containing BLCH-Q), on the 
AACH-Q. 

NOTE 1: The BS always includes the ACCESS-ASSIGN PDU within the AACH. In the present document, the BS 
should include the ACCESS-ASSIGN PDU within the AACH-Q. However, in future editions of the 
present document, the BS may choose not to include the ACCESS-ASSIGN PDU in the AACH-Q in 
some downlink slots on a QAM channel (see clause 21.4.7.1). Therefore the MS should expect that the 
ACCESS-ASSIGN PDU may not be present in the AACH-Q. 

The ACCESS-ASSIGN PDU conveys information about the usage of the downlink slot in which it appears, 
and also access rights for the corresponding (same-numbered) uplink timeslot of that TDMA frame. 

When the uplink is in use for control signalling, the ACCESS-ASSIGN PDU may contain two "Access Fields" 
which convey independent access rights for each of the two uplink subslots in the uplink slot. 

The access field defines the allowed access code for the uplink subslot. It also may include a frame-length 
parameter. Otherwise, it may indicate that the uplink subslot is reserved for use by one MS and is therefore not 
available for random access; or it may assign the subslot for common linearization. 

In other cases (for example, in frames 1 to 17 on an assigned SCCH), the ACCESS-ASSIGN PDU contains 
only one access field, which conveys access rights for both uplink subslots in the uplink slot. 

When the uplink is in use for traffic, the ACCESS-ASSIGN PDU contains no access field, in which case the 
uplink slot is not available for random access or common linearization. 

NOTE 2: If the AACH or AACH-Q is not decodeable or, on a QAM channel, if the ACCESS-ASSIGN PDU is not 
present within the AACH-Q, the MS regards the corresponding uplink slot as not available for random 
access or common linearization. 

Also, the SYSINFO PDU (and the SYSINFO-Q PDU) may include some default parameters to be assumed, for access 
code A, by MSs that have acquired the main carrier (until receipt of ACCESS -DEFINE PDUs). For BSs that do not 
need multiple access codes, the facilities provided by the SYSINFO (and SYSINFO-Q) PDU may be adequate, so that 
the ACCESS-DEFINE PDU is not used. 

The BS may optimize the system performance by varying the access code bindings, the frame-length and the other 
access parameters. The choice of parameters will depend on the type of system and the traffic mix. 

23.5.1 .2.2 Overview of random access channel on 25 kHz channel 

The basic format of the random access channel is illustrated in figures 23.9 to 23.12 inclusive. 

NOTE: In these representations, the detailed TDMA frame structure (e.g. with a control timeslot and three traffic 
timeslots per TDMA frame) is not shown. The uplink control subslots (half timeslots) for this control 
channel are shown as if they were contiguous. 

Figure 23.9 illustrates an example of designation of uplink subslots on a common control channel, showing multiple 
access codes and reserved subslots. The designation is performed using the ACCESS-ASSIGN PDU, with two access 
fields in the ACCESS-ASSIGN PDU defining the use of the two corresponding uplink subslots. 
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Figure 23.9: Example of subslot structure on common control channel 

Figure 23.10 illustrates an example of designation of uplink subslots on an assigned SCCH, showing multiple access 
codes and reserved subslots. The designation is performed using the ACCESS-ASSIGN PDU, with a single access field 
in the ACCESS-ASSIGN PDU defining the use of the two corresponding uplink subslots. 
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Figure 23.10: Example of subslot structure on assigned SCCH 

Now consider only those subslots relevant to a particular access code. For these subslots, requests from MSs are invited 
within access frames. The access field in the ACCESS-ASSIGN PDU indicates the number of following uplink 
subslots, for this access code, that constitute an access frame. A special value ("ongoing frame") is used when the field 
does not mark the start of a new access frame. 

When a user request is initiated, for example valid for access code A, the MS-MAC is permitted to send a first random 
access request in the next access code A subslot, provided that this occurs within a designated time. Otherwise the 
MS-MAC waits for an ACCESS-ASSIGN PDU containing a frame marker for access code A, and then chooses a 
subslot randomly from this access frame for its random access request. An MS-MAC wishing to send a repeat 
transmission after an unsuccessful access request waits for a new frame marker before choosing another subslot 
randomly from that access frame. 

This procedure is illustrated in figures 23. 11 and 23.12, in which the subslots shown are only those control subslots 
marked for random access by access code A. WT is the re-try time when the MS -MAC decides that its access request 
has failed. 

In figure 23.1 1, the BS chooses to mark rolling access frames, with a new access frame marked in every subslot so that 
the access frames clearly overlap. In figure 23.12, the BS chooses to mark discrete access frames, by using the "ongoing 
frame" value (here denoted by *) to indicate continuation. The MS procedures operate independently of this BS choice. 
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Figure 23.12: Example of random access procedure (BS using discrete access frames) 

In either case, the BS may assess activity on the upHnk channel in the subslots assigned to the access code, and may 
vary the frame-length to prevent excessive collision and to minimize access delays. Under normal conditions, the 
frame-length can be short. Then, when collision is detected, the BS may increase the frame-length dynamically 
according to its estimate of the backlogged traffic. This allows rapid smoothing of traffic transients. 

23.5.1 .2.3 Overview of random access channel on 50 kHz, 1 00 kHz or 1 50 kHz 

QAM channel 

There is an additional step in the procedure for random access on 50 kHz, 100 kHz and 150 kHz QAM channels as 
follows. 

Access requests are sent within a 25 kHz bandwidth for all QAM channels. Each subslot (i.e. half timeslot) that is 
available for random access is divided into 25 kHz frequency blocks - called random access uplink RF channel 
subslots - so that each subslot provides: 

• 2 random access uplink RF channel subslots on a 50 kHz channel; 

• 4 random access uplink RF channel subslots on a 100 kHz channel; or 

• 6 random access uplink RF channel subslots on a 150 kHz channel. 

The MS uses the normal procedures for choosing a subslot randomly from an access frame and then counting the 
subslots to its chosen subslot. Thus, for the purposes of counting subslots in an access frame, the parallel random access 
uplink RF channel subslots are regarded as a single subslot. However, when the MS reaches its chosen subslot, there is 
then an additional procedure whereby the MS makes a random choice of one of the 2, 4 or 6 random access uplink RF 
channel subslots corresponding to its chosen subslot. The MS then transmits its access request in the selected random 
access uplink RF channel subslot. 

23.5.1 .3 Access control facilities for BS 

See also the MS random access protocol (clause 23.5.1.4). 



23.5.1.3.1 



Transmission of ACCESS-DEFINE and ACCESS-ASSIGN PDU 



The BS may transmit ACCESS-DEFINE PDUs at intervals decided by the operator. The BS shall transmit the 
ACCESS-ASSIGN PDU in every downlink timeslot on a 7i/4-DQPSK or D8PSK channel, and should transmit the 
ACCESS-ASSIGN PDU in every downlink timeslot on a QAM channel (except slots containing BLCH-Q). The 
formats of the ACCESS-DEFINE and ACCESS-ASSIGN PDUs are defined in clause 21. Between them, these PDUs 
shall indicate: 

• the configuration of the random access channel for this control channel; 

• the valid priorities and the MSs eligible for each uplink subslot; 

• the frame-lengths to be used; and 

• other ALOHA re-try parameters. 
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Also, the BS may include in the SYSINFO (and SYSINFO-Q) PDU some default random access parameters to be 
assumed by MSs, for access code A, until receipt of ACCESS-DEFINE PDUs. 

The following points may be noted: 

a) MSs that have missed ACCESS-DEFINE PDU broadcasts will be unaware of some of the current access 
restrictions and will be applying the limitations of the last received ACCESS-DEFINE PDU (or SYSINFO or 
SYSINFO-Q information). 

b) MSs count subslots in access frames using only the ACCESS-ASSIGN PDUs that they receive. Therefore, in 
case of un-decodeable ACCESS-ASSIGN PDUs, not all MSs will count the subslots in exactly the same way. 

c) Use of the ACCESS-DEFINE PDU is not required if the facilities provided within the SYSINFO and 
SYSINFO-Q PDU are adequate for a particular BS. 

d) The "Timeslot Pointer" element in the ACCESS-DEFINE PDU (and SYSINFO and SYSINFO-Q) allows the 
BS to define those timeslots per TDMA frame that can be used for random access by MSs on this control 
channel, independently of the downlink channel configuration. For example, the BS may define an extended 
random access channel, allowing additional random access opportunities. The BS may define an extended 
random access channel for a common control channel (i.e. MCCH or common SCCH) or for an assigned 
channel. 

The ACCESS-ASSIGN PDU then indicates (on a slot-by-slot basis) whether each uplink random access slot is 
available for common use or only for MSs on an assigned channel. This allows flexible use of the uplink 
e.g. in the case of an extended random access channel or in the case of minimum mode. 

e) The BS designer should note the default assumptions for an MS when it acquires the main carrier or changes 
channel within the cell. 

23.5.1 .3.2 BS response to access request 

After receiving an MS random access request, the BS should respond with a MAC-RESOURCE PDU indicating 
successful random access. The response may be sent in the corresponding downlink timeslot in the next TDMA frame 
(if that slot is appropriate to the downlink control channel). Alternatively the response may be delayed. The WT 
parameter in the ACCESS-DEFINE PDU defines the time the MS-MAC will wait before deciding to retransmit; see 
clause 23.5.1.4. 

The BS should return the response in a timeslot on the MS's downlink control channel. In the case of a multi-slot 
downlink control channel, the BS may return the response in any slot of that downlink control channel. 

If there is any possible ambiguity about the requesting MS's downlink configuration, the BS may return the response in 
more than one downlink slot. 

If the BS is ready to return an LLC response or a layer 3 message (e.g. D-CALL PROCEEDING or D-CONNECT 
ACKNOWLEDGE) to the requesting MS at the time when it sends the MAC-RESOURCE response PDU, then it may 
carry a TM-SDU in the MAC-RESOURCE PDU. Otherwise it should send a dedicated MAC response PDU. 

23.5.1 .3.3 Reserving subslots on uplink 

During an access frame, the BS may transmit PDUs that demand a response from a specific MS (e.g. the D-SETUP 
PDU). To allow the MS to respond without making a random access, the BS may reserve a subslot or slot(s) for the 
response. The ACCESS-ASSIGN PDU indicates which subslots are reserved and therefore not available for random 
access. The MS for which a subslot or slot(s) are reserved shall be informed in the downlink signalling channel (see 
clause 23.5.2). 

The ACCESS-ASSIGN PDU also indicates subslots that are available for common use for linearization (and therefore 
not available for random access). 
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23.5.1 .4 MS-MAC random access protocol 

The general random access procedure is described in clauses 23.5.1.4.1 to 23.5.1.4.9; this procedure covers normal 
operation on one 7i/4-DQPSK control channel (common, assigned or multi-slot). Then any variations in operation for 
different channel configurations are described in clauses 23.5.1.4.10 to 23.5.1.4.18. 

23.5.1 .4.1 Reception of ACCESS-DEFINE PDU 

The MS-MAC shall continuously receive the downlink control channel, looking for ACCESS-DEFINE PDUs (within 
the constraints of the energy economy or dual watch regime or the napping procedures, and the cell reselection 
procedures, and linearization and transmission requirements). The downlink slot(s) appropriate to this control channel 
are known from the SYSINFO PDU (BNCH) or from the "Timeslot Assigned" element in the MAC-RESOURCE or 
MAC-END PDU that sent the MS to the channel. An ACCESS-DEFINE PDU defines access restrictions and access 
parameters for one access code. 

On receipt of an ACCESS-DEFINE PDU, the MS-MAC shall note the minimum vahd PDU priority for the access 
code; also, if included, the MS-MAC shall note the eligible subscriber classes or group address. If the 
ACCESS-DEFINE PDU does not include a "subscriber class bit map" element, the MS-MAC shall assume that there is 
no subscriber class restriction. If the ACCESS-DEFINE PDU does not include a "GSSI" element, the MS-MAC shall 
assume that there is no address restriction. 

The MS-MAC shall note the ALOHA parameters (IMM, WT, Nu, frame-length factor). It shall also note from element 
"Timeslot Pointer" which uplink slots are potentially available for random access on this control channel i.e. the valid 
pattern for attempting to receive and decode the AACH for access invitations. If Nu is set to in the ACCESS-DEFINE 
PDU, this indicates that the access code is not available for use. 

The MS-MAC shall comply with the received ACCESS-DEFINE parameters for random access attempts on this access 
code and control channel. Each parameter set shall remain valid until updated by a subsequent ACCESS-DEFINE PDU 
for this access code and with the same setting of the "Common or assigned control channel flag", received on this 
downlink control channel. 

NOTE 1: A subsequent ACCESS-DEFINE PDU for this access code overwrites the previous definition even if the 
addressing mechanism (i.e. subscriber class bit map, GSSI or neither) is not the same. 

An MS on the MCCH or on a common SCCH shall ignore any received ACCESS-DEFINE PDUs containing "Common 
or assigned control channel flag" = 1 (i.e. assigned). Similarly, an MS on a channel assigned for SCCH or for a circuit 
mode call shall ignore any received ACCESS-DEFINE PDUs containing "Common or assigned control channel 
flag" = (i.e. common). 

NOTE 2: The "Timeslot Pointer" element may give a bit map of the appropriate timeslots for the random access 
channel for this control channel, or it may be set to OOOO2 (i.e. same as downlink slot assignment). The 
latter means: 

slot 1 if the MS is on the MCCH; 

■ the appropriate slot for this MS when common SCCHs are in use; or 

■ the same timeslot number(s) as for the "Timeslot Assigned" element from the MAC -RESOURCE 
or MAC -END PDU in the case of an assigned channel. 

23.5.1 .4.2 Reception of ACCESS-ASSIGN PDU 

If the MS-MAC wishes to send a random access message, and knows a valid access code for the message, it shall 
attempt to decode the appropriate downlink AACH which contains the ACCESS-ASSIGN PDU. The MS should look 
for the AACH in all the slots defined by element "Timeslot Pointer" from the ACCESS-DEFINE PDU (or the default 
value from the SYSINFO PDU), in all frames 1 to 18. 

If an ACCESS-ASSIGN PDU contains two access field elements then "Access field 1" conveys access rights to 
subslot 1 in the corresponding uplink slot, i.e. the same-numbered uplink timeslot of that TDMA frame. "Access 
field 2" conveys independent access rights to subslot 2 in the uplink slot. 
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If an ACCESS-ASSIGN PDU contains only one access field, this conveys access rights to both subslots of the 
corresponding uplink slot as follows: 

a) the same access code shall be assumed for both subslots; 

b) when the access field indicates "Reserved subslot", it shall be assumed that both subslots are reserved; 

c) when the access field indicates "CLCH(-Q) subslot", it shall be assumed that subslot 1 may be used for 
linearization, and that subslot 2 is reserved; 

d) when the access field indicates "Ongoing frame", it shall be assumed that ongoing frame applies to both 

subslots; 

e) when the access field indicates a frame marker base frame-length of > 1 subslots, it shall be assumed that the 
frame marker base frame-length applies to subslot 1, and that "Ongoing frame" applies to subslot 2. 

If an ACCESS-ASSIGN PDU contains no access field (i.e. traffic on uplink) then both the corresponding uplink 
subslots shall be regarded as reserved. 

If an MS on the MCCH or on a common SCCH receives an ACCESS-ASSIGN PDU indicating that the uplink slot is 
designated as "Assigned only", then both the corresponding uplink subslots shall be regarded as reserved. 

If an MS on an assigned channel (assigned for SCCH or for a circuit mode call) receives an ACCESS-ASSIGN PDU 
indicating that the uplink slot is designated as "Common only", then both the corresponding uplink subslots shall be 
regarded as reserved. 

If the AACH is un-decodeable then both the corresponding uplink subslots shall be regarded as reserved. 

NOTE: As defined in clause 9, the start of the TDMA frame (and multiframe and hyperframe) on the uplink is 
delayed by a fixed period of two timeslots from the start of the TDMA frame (or multiframe or 
hyperframe) on the downlink. So the ACCESS-ASSIGN PDU in a downlink slot conveys access rights to 
the corresponding uplink slot, which is two slots later. 

23.5.1 .4.3 Initiating a random access 

The MS shall only make one random access attempt at a time, per control channel. A random access attempt refers to 
the period from initiation of the random access procedure until a response is received or the procedure is abandoned. 

When the MS has individually addressed unscheduled signalling messages to send, as indicated by the 
DATA-IN -BUFFER signal from the LLC, the MS-MAC may initiate the random access procedure if it: 

a) does not have a reserved subslot or slot(s) already granted for this address on this control channel; and 

b) has not already indicated to the BS that it has a signalling requirement for this address on this control channel 
(by asking for a reserved subslot or slot(s)). 

NOTE 1: The ISSI and its associated ASSI are equivalent for the purposes of the slot granting procedure (so the 
MS should use any subslot or slot(s) granted on its ISSI for messages sent with its ASSI, or vice versa). 
Similarly, an event label and its corresponding address are equivalent for the purposes of the slot granting 
procedure. Also, a newly assigned ASSI is equivalent to the replaced ASSI or USSI for the purposes of 
the slot granting procedure. 

NOTE 2: As defined above, the MS is permitted to initiate the random access procedure if the MS has individually 
addressed unscheduled signalling messages to send and criteria a) and b) are satisfied. This applies either 
if the MS has only unscheduled signalling messages to send or if it has both unscheduled and fully 
scheduled signalling messages to send. However, in the latter case, the MS may choose to delay initiation 
of the random ac cess procedure in some cases. For example, it could decide to delay initiation of the 
random access procedure if the lowest value of the maximum schedule interval for the fully scheduled 
data (as indicated by the DATA-IN -BUFFER signal from the LLC) is small. 

NOTE 3: If the MS has only fully scheduled signalling messages to send, it is not permitted to initiate the random 
access procedure unless the criteria in clause 23.5.2.4.2 are satisfied. 
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Also, the MS-MAC may initiate the random access procedure if it does not have a reserved subslot or slot(s) already 
granted for this address on this control channel, and the LLC indicates that a new emergency unscheduled message has 
just been received from layer 3, as indicated by the PDU priority parameter set to 7 in the DATA-IN-BUFFER signal. 

NOTE 4: This exception allows the MS-MAC to cut short the reserved access waiting time-out T.206 in case of 
emergency; see clause 23.5.2.4. L The MS may then send the emergency message by random access. 

If the MS-MAC was in the process of sending a fragmented message at the time when it decides to cut 
short the reserved access waiting time-out T.206, it should discard the partially sent TM-SDU. 

When the MS has individually addressed unscheduled signalling messages to send, and has indicated a signalling 
requirement for this address on this control channel, and does not have a reserved subslot or slot(s) granted for this 
address on this control channel, the MS-MAC may initiate the random access procedure if the criteria in 
clause 23.5.2.4.1 are satisfied. 

Also, if the MS supports data priority, and has individually addressed signalling messages to send, and has indicated a 
signalling requirement for this address on this control channel, and does not have a reserved subslot or slot(s) granted 
for this address on this control channel, the MS-MAC may initiate the random access procedure if the criteria in 
clause 23.4.7.5.2 or clause 23.4.7.5.3 are satisfied. 

When the MS has fully scheduled signalling messages to send, the MS-MAC may initiate the random access procedure 
if the criteria in clause 23.5.2.4.2 are satisfied. 

The random access request shall be sent using the MAC-ACCESS PDU, fitting within a single subslot on the uplink 
(SCH/HU) and containing a TM-SDU or first fragment if appropriate. Any TM-SDU to be sent, or TM-SDUs if using 
association, are received from the LLC in the TMA-UNITDATA request primitive. 

If the MS has any further signalling to send for this address on this control channel, the MS-MAC shall include a 
request for reserved capacity in the MAC- ACCESS PDU. 

When the MS-MAC is required to initiate a random access, it shall comply with the access parameters. If the access 
request is not valid for any of the current access codes (as specified in clauses 23.5.L4.1 and 23.5. L4. 4), the MS -MAC 
may immediately abandon the random access attempt, reporting the failure to the LLC using the TMA-REPORT 
indication primitive. 

23.5.1 .4.4 Checking for appropriate access code 

When the MS -MAC wishes to send a non-emergency message, it shall not use a subslot designated for a particular 
access code unless the following criteria are all satisfied: 

a) the PDU priority, as supplied in the TMA-UNITDATA request primitive, is equal to or higher than the 
minimum PDU priority for this access code; 

b) if subscriber class is restricted for this access code: the subscriber class information, as supplied in the 
TMA-UNITDATA request primitive, is eligible for this access code; 

c) if address is restricted for this access code: the designated GSSI is one of the MS's valid group addresses. 

For an emergency message, the same criteria shall apply for access codes B, C and D. However, the MS may use access 
code A for an emergency message without checking the above criteria. 

For a message sent when the MS does not yet have subscriber class information for this network, criterion b) need not 
be checked. 

NOTE 1: In criterion b), the eligibility for subscriber class requires that, for at least one class, the class is invited by 
the ACCESS-DEFINE PDU (i.e. there is a "1" in the appropriate position) and the MS belongs to that 
class. 

NOTE 2: The message is an "emergency message" if the PDU priority parameter in the TMA-UNITDATA request 
primitive indicated the highest priority, i.e. 7. 

NOTE 3: The exemption from checking criterion b) when the MS does not yet have subscriber class information 
for this network applies during migration. It applies also if the MS has not yet registered and did not 
receive subscriber class information at subscription. 
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23.5. 1 .4.5 First try procedure 

There is a special procedure for the first random access transmission. 

The MS-MAC shall transmit its random access request in the first uplink slot in which one or both subslots are valid 
access opportunities (i.e. slot corresponds to element "Timeslot Pointer" and has an appropriate common/assigned 
designation, and subslot has an appropriate access code and is not reserved nor assigned for linearization) if: 

a) it is an emergency message; or 

b) parameter IMM = 15; or 

c) 1 < IMM < 14, and the valid access opportunity occurs within the IMM TDMA frames following the initiation 
of the random access procedure. 

If both the subslots in the uplink slot are valid access opportunities, the MS-MAC shall choose one of the two subslots 
randomly. This rule applies only to this first try procedure. 

If the above conditions are not met, then the MS-MAC shall choose a subslot from a new access frame (see 
clause 23.5.1.4.6). 

If a complete TM-SDU is contained within the MAC-ACCESS PDU, then the MS-MAC shall report to the LLC when 
the first random access transmission has been sent using the TMA-REPORT indication primitive. 

23.5.1 .4.6 Choosing from a new access frame 

An MS -MAC that requires to select a subslot from a new access frame shall wait for a suitable access frame marker 
i.e. an ACCESS-ASSIGN PDU in a slot corresponding to element "Timeslot Pointer" with an access field that contains: 

• a frame marker ("Base Frame-length" of > 1 subslots); and 

• an appropriate uplink slot designation (common/assigned); and 

• an appropriate access code (as defined in clause 23.5.1.4.4), 

with the most recently received access code parameters enforced at this time. 

The MS-MAC shall then select a subslot randomly from the specified access frame. That is, it shall choose a subslot 
randomly between 1 and "Frame-length" using a uniform distribution, where: 

if the "frame-length factor" for this access code = 
then Frame-length = 1 x Base Frame-length 
else Frame-length = 4 x Base Frame-length. 

The MS-MAC shall transmit its access request in the chosen subslot, unless the random access attempt is abandoned 
(see clause 23.5. 1.4.9). 

23.5.1 .4.7 Counting subslots in an access frame 

The uplink subslot corresponding to the frame marker access field is defined as the first subslot in the access frame. 

When counting further access subslots to its chosen subslot in the access frame, the MS -MAC shall count a subslot only 
if: 

a) it was indicated by element "Timeslot Pointer" in the ACCESS-DEFINE PDU (or, for access code A, in the 
SYSINFO PDU if the default definition is still valid); and 

b) the corresponding ACCESS-ASSIGN PDU is received; and 

c) the uplink slot designation (common/assigned) is appropriate for this control channel; and 

d) the subslot is marked with the appropriate access code, i.e. the access code used when choosing from the 
access frame; and 

e) the subslot is not designated as reserved or assigned for linearization. 



£75/ 



802 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

NOTE: Subslots for this code designated as "ongoing frame" are counted, and also subslots starting new access 
frames; a new access frame marker does not alter a subslot choice already made. 

23.5.1.4.8 Re-try procedure 

After sending an access request, the MS-MAC shall wait for a response from the BS, i.e. a MAC-RESOURCE PDU on 
the downlink control channel, containing the same address as in the access request and with the "random access flag" 
indicating successful random access. If a complete TM-SDU was contained within the MAC-ACCESS PDU, the 
MS-MAC shall report the success to the LLC using the TMA-REPORT indication primitive. Then, if the received 
MAC-RESOURCE PDU contains a TM-SDU, the MS-MAC shall deUver that TM-SDU to the LLC using the 
TMA-UNITDATA indication primitive. 

The MS-MAC shall look for the response in all downlink slots appropriate to this downlink control channel, as 
indicated by the S YSINFO PDU or by the MAC-RESOURCE or MAC-END PDU that sent the MS to the channel. The 
first potential slot in which the response may be received is the corresponding downlink slot in the next TDMA frame, 
i.e. the same timeslot number as the request slot, if that slot is appropriate to the downlink control channel. This allows 
the MS approximately one timeslot duration for switching from transmission to reception. 

If a response is not received within the WT downlink signalling opportunities after transmission of its access request, 
the MS-MAC shall assume that the transmission has failed. Then it shall either: 

a) abandon its random access attempt (see clause 23.5.1.4.9 point a); or 

b) select a further subslot randomly from a new access frame, as in clause 23.5.1.4.6, and using a frame marker 
ACCESS-ASSIGN PDU received in or after the WT'th downlink signalling opportunity following the 
unsuccessful access request. However, if the MS-MAC receives a response before sending a repeat message, it 
shall accept the response and not retransmit. 

When counting slots (i.e. downlink signalling opportunities) for time-out WT, the MS-MAC shall count only one slot 
per TDMA frame, namely the downlink slot with the same timeslot number as the request slot or, if that slot is not 
appropriate to the downlink control channel, then the next slot that is appropriate to the downlink control channel. 

On an assigned channel, the MS-MAC shall count the downlink slot only if it is available for control. Downlink slots in 
frames 1 to 17 for which the ACCESS-ASSIGN PDU (or last received ACCESS-ASSIGN PDU in frames 1 to 17) 
indicates downlink user traffic should not be counted in the time-out WT. However, the BS may choose to send the 
response by stealing from the downlink TCH. 

NOTE 1: Downlink user traffic in frames 1 to 17 is indicated by Header t- OO2 and downlink usage 
marker > OOOIOO2. 

NOTE 2: The above procedure allows for possible cases of independent allocation of uplink and downlink. 

NOTE 3: As defined above, the MS looks for a response in all downlink slots appropriate to that channel. However 
a maximum of one slot per TDMA frame is counted for time-out WT. This is equivalent to the method for 
timers T.202 and T.206, and some LLC timers. It contrasts with the method for counting uplink 
opportunities for the granting delay for reserved access, when all slots on a multi-slot channel are 
counted; and with the method for counting access subslots in an access frame, when all appropriate 
subslots are counted. 

23.5.1 .4.9 Abandoning random access attempt 

The MS-MAC shall cease attempting random access if it receives a response from the BS, as described in 
clause 23.5.1.4.8, or if any of the following occurs: 

a) The MS-MAC has sent the current maximum permitted number of random access transmissions without 
receiving a response; the maximum number of transmissions is Nu for a message with PDU priority to 6, or 
2 X Nu for a message with PDU priority 7. The failure shall be reported to the LLC using the TMA-REPORT 
indication primitive. 

b) A time T.205 has elapsed since initiation of the random access procedure. The failure shall be reported to the 
LLC. 
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c) The MS-MAC receives a TMA-CANCEL request primitive from the LLC, cancelling transmission of this 
message. The MS-MAC shall abandon the random access attempt whether or not it has sent any transmissions, 
reporting the state of transmission to the LLC. 

d) The MS-MAC receives a MAC-RESOURCE (or MAC-END or MAC-D-BLCK) PDU that does not indicate 
successful random access but grants a reserved subslot or slot(s) for this address. The MS-MAC shall send a 
PDU (or PDUs) in the reserved capacity, e.g. its own request and/or the message demanded by the BS. If the 
MS has any further signalling ready to send for this address on this control channel, the MS-MAC shall 
include the "reservation requirement" element in its transmission. 

If a complete TM-SDU is transmitted, the MS-MAC shall report to the LLC that the message has been sent by 
reserved access. 

Also, if the access request becomes ineligible for the current definition of the access codes, the MS-MAC may abandon 
the random access attempt, reporting the failure to the LLC. 

If the MS-MAC abandons a random access attempt without having received a response from the BS, it shall not initiate 
any new random access attempt until any ongoing WT timer from the last request has expired. 

23.5.1 .4.1 Random access operation after acquiring main carrier 

The MS-MAC shall make the following assumptions about the random access parameters on first acquiring a main 
carrier or receiving a channel allocation for a new cell. 

If the MS-MAC has received the "default definition for access code A" element in the SYSINFO PDU then it shall 
assume the most recently received SYSINFO parameters for access code A, and with no MAC subscriber class 
restriction or address restriction, until it receives an ACCESS-DEFINE PDU for access code A. Otherwise it shall not 
use access code A until it receives either the SYSINFO default definition for access code A or an ACCESS-DEFINE 
PDU for access code A. 

The MS-MAC shall not use access code B, C or D until it receives the appropriate ACCESS-DEFINE PDU. 

NOTE 1 : These parameters apply both to the MCCH and to a common SCCH. 

There is no time limit on the validity of use of the SYSINFO parameters, since some BSs may choose never to send the 
ACCESS-DEFINE PDU, relying solely on the SYSINFO default definition for access code A. Until receipt of a 
"common" ACCESS-DEFINE PDU for access code A, the MS shall assume the most recently received SYSINFO 
parameters. After receipt of a "common" ACCESS-DEFINE PDU for access code A, the MS shall ignore any access 
parameters received in SYSINFO PDUs, reverting to the procedure in clause 23.5.1.4.1. 

NOTE 2: The validity of use of the SYSINFO parameters on the MCCH or a common SCCH is not affected by 
receipt of an ACCESS-DEFINE PDU with "Common or assigned control channel flag" = 1 
(i.e. assigned). Receipt of an "assigned" ACCESS-DEFINE PDU for access code A while the MS is on 
the MCCH or a common SCCH does not affect the validity of the SYSINFO parameters. Receipt of an 
"assigned" ACCESS-DEFINE PDU for access code A while the MS is on an assigned channel over-rides 
the SYSINFO definition while the MS is on that assigned channel, but does not affect operation when the 
MS returns to the MCCH or to a common SCCH. 

23.5.1 .4.1 1 Random access operation on a new channel 

When an MS is sent to a new channel within the cell, it shall make the following assumptions about the random access 
parameters, until updated by ACCESS-DEFINE PDUs or the SYSINFO definition. 

a) When changing channel to the MCCH or to a common SCCH, the MS-MAC shall assume that all random 
access parameters except the "Timeslot Pointer" are equal to those used when the MS -MAC last received 
either the MCCH or a common SCCH (parameters as received in SYSINFO and/or ACCESS-DEFINE PDUs). 
This rule applies both when the BS has changed the number of common SCCHs in use and when the 
MS-MAC returns from an assigned channel. 

The MS-MAC shall assume that the random access channel uses the same timeslot as the current downlink 
assignment. 
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b) For an assigned channel (either for SCCH or for a circuit mode call): 

For the "Timeslot Pointer", the MS-MAC shall assume the same timeslot number(s) as for the "Timeslot 
Assigned" from the MAC-RESOURCE or MAC-END PDU; 

The MS-MAC shall assume that the other parameters are equal to those on the old channel except that, 
for access code A, the MS-MAC shall assume "Frame-length Factor" = 0, "Minimum PDU Priority" 
= OOO2 and no subscriber class restriction or address restriction. 

The MS-MAC may continue an ongoing random access attempt on the new channel, but shall choose a subslot from a 
new access frame using an appropriate frame marker received on the new channel. 

The random access parameters shall all be updated on receipt of an appropriate ACCESS-DEFINE PDU on that 
channel. If the MS is on the MCCH or a common SCCH, and is still using the SYSINFO default definition, then the MS 
shall update the parameters on receipt of a new SYSINFO definition on that channel. If the MS is on an assigned 
channel, and is still using the SYSINFO default definition on that channel, then the MS shall update the parameters on 
receipt of a new SYSINFO definition on that channel, except for parameters "Timeslot Pointer", "Frame-length Factor" 
and "Minimum PDU Priority" for which it shall retain the values given in b) above. 

23.5. 1 .4. 1 2 Random access operation on ACCH 

If the MS-MAC wishes to send a random access message on a channel allocated for a circuit mode call, it shall obey the 
normal procedures but with the following differences. 

If the MS is transmitting traffic in frames 1 to 17 and sends a random access request in frame 18 then, when counting 
downlink slots for waiting time WT, the MS shall count only those slots that it is required to attempt to receive and 
decode, according to the assigned monitoring pattern(s), and are available for control (see clause 23.5.1.4.8). 

NOTE 1: As in clause 23.5.1.4.8, the MS counts a maximum of one slot per TDMA frame for waiting time WT. 

NOTE 2: For a multi-slot channel, if the MS is not frequency full duplex, and if the BS assigns monitoring 

pattern(s) that the MS is not capable of following, then, when counting for waiting time WT, the MS 
counts only those downlink TDMA frames containing at least one slot that it is able to attempt to receive 
and decode and that is available for control. 

For a multi-slot channel, if the MS is not frequency full duplex, and if there is currently traffic on the downlink, then the 
MS is not required to transmit a random access request if it would thereby miss downlink traffic. The MS may regard 
unsuitable uplink subslots as reserved. 

Similarly, for a multi-slot channel, if the MS is not frequency full duplex, and if the MS is currently performing a 
reconstruction of a downlink TM-SDU, then the MS is not required to transmit a random access request if it would 
thereby cause the reconstruction to fail. The MS may regard unsuitable uplink subslots as reserved. This applies for any 
multi-slot assigned channel i.e. assigned either for SCCH or for a circuit mode call. 

23.5.1.4.13 Random access operation in minimum mode 

During minimum mode, the MS -MAC shall follow the defined minimum mode rules for receiving and decoding the 
downlink for signalling messages - in slot 1 of frames 1 to 17 and in its designated minimum mode slot in frame 18. 

When an MS-MAC enters minimum mode, the most recently received access definitions shall apply. If the MS-MAC 
then receives ACCESS-DEFINE PDUs in the downlink slots that it is required to receive, it shall obey the 
ACCESS-DEFINE definition for PDUs containing "Common or assigned control channel flag" = (i.e. common); but 
shall ignore ACCESS-DEFINE PDUs containing "Common or assigned control channel flag" = 1 (i.e. assigned). 

If an MS-MAC in minimum mode wishes to send a random access message, the valid pattern for attempting to receive 
and decode the AACH for access invitations and for counting subslots in an access frame is: 

• in frames 1 to 17: the slot(s) defined by the current setting of "timeslot pointer"; 

• in frame 18: all four slots. 

Only those uplink slots marked in the ACCESS-ASSIGN PDU as available for common access are applicable. 
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The procedures defined in preceding clauses for choosing a subslot for the first and subsequent random access 
transmissions shall apply. When counting downlink slots for waiting time WT, the MS shall count only its designated 
minimum mode frame 18 slot. However, the BS may choose to send the response in slot 1 of the assigned channel 
during frames 2 to 17, either by stealing or within the assigned channel's FACCH (as described in clause 23.3). 

NOTE: The above minimum mode procedure applies only to those MSs that are in common control mode and 
receiving the MCCH. It does not apply to MSs on an assigned channel. 

23.5.1.4.14 Random access operation on time-shared control channel 

On a time-shared MCCH, the MS-MAC shall follow the defined rules for receiving and decoding the downlink for 
signalling messages. 

If the MS-MAC wishes to send a random access message, it shall obey the normal procedures but with the following 
differences: 

• The rules for attempting to receive and decode the AACH for access invitations and for counting subslots in an 
access frame (according to element "Timeslot Pointer") shall apply only to the frames reserved for this BS and 
the common frames. 

• For 1 < IMM < 14, IMM shall be replaced by: 

IMM X 12 / TS-RES, for TS-RES = 1, 2, 3, 4, 6; 
IMM X 36 / TS-RES, for TS-RES = 9, 12, 18; 
where TS-RES is the number of reserved frames per two multiframes for this BS. 

• When counting downlink slots for waiting time WT, the MS shall count only slot 1 of the frames reserved for 
this BS. However, the BS may choose to send the response in slot 1 of one of the common frames. 

For a time-shared common SCCH, "slot 1" in the above shall be replaced by the appropriate slot number on the main 
carrier. 

23.5.1 .4.1 5 Random access operation on CSS channel 

On a CSS channel, the MS-MAC shall generally apply the random access procedures defined in the earlier clauses 
within clause 23.5.1.4 as if the CSS channel were an independent single-slot 7i/4-DQPSK assigned channel allocated by 
a specific MAC-RESOURCE or MAC-END PDU with "Timeslot Assigned" = IOOO2 (see clause 23.5.4.2.1 d)). So, for 
example: 

a) The ALOHA parameters (e.g. IMM, WT, Nu, frame-length factor) received on the CSS downlink channel 
apply to the CSS random access channel. 

b) An uplink slot has an appropriate common/assigned designation only if it is designated as "common and 
assigned" or "assigned only". 

However, the following differences shall apply: 

1) As defined in clause 23.5.4.2.1 d), the MS is only required to receive the CSS channel within the capabilities 
of that MS. 

2) If the MS is not frequency full duplex then it is not required to transmit a random access request on the CSS 
channel if it would thereby miss downlink traffic on an assigned channel or cause a reconstruction on an 
assigned channel to fail. The MS may regard unsuitable uplink subslots on the CSS channel as reserved. 

3) After sending a random access request on the CSS channel and not receiving a response within the waiting 
time WT, the MS may send a retry either on the CSS channel or alternatively on the appropriate assigned 
channel. Conversely, after sending a random access request on an assigned channel and not receiving a 
response within the waiting time WT, the MS may send a retry either on the same assigned channel or 
alternatively on the CSS channel. When the MS wishes to send a retry on a channel, it shall choose a subslot 
from a new access frame using an appropriate frame marker received on that channel. 
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When the MS obeys a channel allocation with "allocation type" = 1 12 (i.e. Replace + CSS channel) where the specified 
carrier is the main carrier, the MS may, if capable, use the MCCH or the appropriate common SCCH for that MS in 
addition to the assigned channel (see clause 23.5.4.2.1 d)). Then the same random access procedures shall apply on the 
MCCH or common SCCH as defined above for a CSS channel except that the MS shall regard the MCCH or common 
SCCH as a common control channel and therefore an uplink slot has an appropriate common/assigned designation only 
if it is designated as "common only" or "common and assigned". 

23.5.1 .4.1 6 Random access operation with extended random access channel 

When an extended random access channel has been defined by the BS, the MS-MAC shall obey the procedures defined 
in the earlier clauses within clause 23.5.1.4. So, for example: 

a) The ALOHA parameters (e.g. IMM, WT, Nu, frame-length factor) received on the downlink control channel 
apply to the extended random access channel defined by element "Timeslot Pointer". 

b) A subslot is a valid access opportunity if the slot corresponds to element "Timeslot Pointer" for this control 
channel and has an appropriate common/assigned designation (as defined in c)), and the subslot has an 
appropriate access code and is not reserved nor assigned for linearization. 

c) If the MS is on a common control channel (i.e. MCCH or common SCCH) then the slot has an appropriate 
common/assigned designation only if the uplink slot is designated as "common only" or "common and 
assigned". 

If the MS is on an assigned channel then the slot has an appropriate common/assigned designation only if the 
uplink slot is designated as "common and assigned" or "assigned only". 

NOTE 1 : Thus the MS applies the same check on the common/assigned designation to all slots of the random 
access channel defined by element "Timeslot Pointer", irrespective of whether the same-numbered 
downlink slot is part of the downlink control channel. 

d) When the MS chooses a subslot from a new access frame, it may use a frame marker from any slot 
corresponding to element "Timeslot Pointer" for this control channel if the slot has an appropriate 
common/assigned designation (as defined in c)), and the subslot has an appropriate access code. 

e) When counting access subslots to its chosen slot in an access frame, the MS counts all valid access subslots (as 
defined in b)) i.e. it counts all subslots corresponding to element "Timeslot Pointer" if they have an appropriate 
common/assigned designation and access code and are not reserved nor assigned for linearization. 

Thus all the access subslots corresponding to element "Timeslot Pointer" are equivalent for the purposes of the random 
access procedure. 

When waiting for a response from the BS, the MS looks for the response in the downlink slots appropriate to the 
downlink control channel (as indicated by the S YSINFO PDU or by the "Timeslot Assigned" element in the 
MAC-RESOURCE or MAC-END PDU that sent the MS to the channel). 

NOTE 2: As in clause 23.5. 1 .4.8, the MS counts a maximum of one slot per TDMA frame for waiting time WT. 
See also clauses 23.5.1.4.12, 23.5.1.4.13 and 23.5.1.4.14. 

NOTE 3: In the first sentence of clause 23.5.1.4.3 (i.e. where it is specified that the MS makes only one random 
access attempt at a time, per control channel), the expression "per control channel" refers to the 
combination of the downlink control channel and the extended random access channel. 

23.5.1 .4.1 7 Random access operation on D8PSK channel 

If an MS-MAC on a D8PSK channel wishes to send a random access message, it shall obey the procedures defined in 
the earlier clauses within clause 23.5.1.4. 

The following points may be noted: 

a) The BS sends the ACCESS-ASSIGN PDU using 3i/4-DQPSK modulation, on the AACH. 

b) The MS shall send the random access request using 7i/4-DQPSK modulation, on SCH/HU. 
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c) The BS may send the response MAC-RESOURCE PDU using either a 7i/4-DQPSK burst or a 71/8-D8PSK 

burst. 

d) If the MS is attempting random access and receives a MAC-RESOURCE (or MAC-END or MAC-D-BLCK) 
PDU that does not indicate successful random access but grants a reserved subslot or slot(s) for this address 
(see clause 23.5.1.4.9d), the MS may use either 7i/4-DQPSK or 71/8-D8PSK burst(s) when it transmits in the 
reserved capacity. 

e) In the present document, the only usage of D8PSK channels is for assigned SCCH. Therefore the MS obeys 
the procedures for an MS on an assigned channel as defined in the earlier clauses within clause 23.5.1.4. 

23.5.1 .4.1 8 Random access operation on QAM channel 

If an MS-MAC on a QAM channel wishes to send a random access message, it shall obey the procedures defined in the 
earlier clauses within clause 23.5.1.4, with the following differences: 

1) The BS sends the ACCESS-ASSIGN PDU on AACH-Q. Therefore, where clauses 23.5.1.4.1 and 23.5.1.4.2 
refer to the MS attempting to decode the AACH, the MS shall attempt to decode the AACH-Q instead. 

2) On a QAM channel, the ACCESS-ASSIGN PDU may not be present within the AACH-Q in some downhnk 
slots; see clause 21.4.7.1. Therefore, for the procedure for reception of the ACCESS-ASSIGN PDU 
(clause 23.5.1.4.2), there is an additional procedure for the MS: 

If the ACCESS-ASSIGN PDU is not present within the AACH-Q then both the corresponding uplink 
subslots shall be regarded as reserved. 

NOTE 1 : Thus the MS regards both the corresponding uplink subslots as reserved whenever it does not receive the 
ACCESS-ASSIGN PDU in a downlink slot - either because the AACH-Q is not decodeable or because 
the ACCESS-ASSIGN PDU is not present within the AACH-Q. 

3) The MS shall send the random access request using the MAC- ACCESS PDU on SCH-Q/RA (instead of 
SCH/HU). 

4) For the first try procedure (clause 23.5.1.4.5) and when counting subslots in an access frame 

(clause 23.5.1.4.7), the MS shall use the defined procedures for choosing a transmission slot and subslot in 
time (i.e. subslot 1 or subslot 2). The MS shall then decide which 25 kHz random access uplink RF channel 
subslot SSN-Q to use for the access request as follows: 

for a 25 kHz channel: 

■ if the defined procedures indicate transmission in subslot 1, the MS shall select SSN-Q =11; 

■ if the defined procedures indicate transmission in subslot 2, the MS shall select SSN-Q = 21; 
for a 50 kHz channel: 

■ if the defined procedures indicate transmission in subslot 1, the MS shall choose SSN-Q randomly 
from the range 11 to 12 using a uniform distribution; 

■ if the defined procedures indicate transmission in subslot 2, the MS shall choose SSN-Q randomly 
from the range 21 to 22 using a uniform distribution; 

for a 100 kHz channel: 

■ if the defined procedures indicate transmission in subslot 1, the MS shall choose SSN-Q randomly 
from the range 1 1 to 14 using a uniform distribution; 

■ if the defined procedures indicate transmission in subslot 2, the MS shall choose SSN-Q randomly 
from the range 21 to 24 using a uniform distribution; 
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for a 150 kHz channel: 



■ if the defined procedures indicate transmission in subslot 1, the MS shall choose SSN-Q randomly 
from the range 11 to 16 using a uniform distribution; 

■ if the defined procedures indicate transmission in subslot 2, the MS shall choose SSN-Q randomly 
from the range 21 to 26 using a uniform distribution. 

The MS shall transmit its access request in the selected random access uplink RF channel subslot SSN-Q, 
unless the random access attempt is abandoned. (See also clauses 9.3.2b and 9.3.6a.) 

5) On a QAM channel, the BS sends the SYSINFO-Q PDU on BNCH-Q (instead of sending the SYSINFO PDU 
on BNCH). The SYSINFO-Q PDU contains the same "default definition for access code A" element as in the 
SYSINFO PDU, though the element is always present in the SYSINFO-Q PDU instead of being conditional. 

6) Where clause 23 .5 . 1 .4. 1 1 refers to the MS updating the random access parameters on receipt of a new 
SYSINFO definition on that channel (if it is still using the SYSINFO default definition on that channel), the 
MS shall instead update the random access parameters on receipt of a new SYSINFO-Q definition on that 
channel (if it is still using the SYSINFO-Q default definition on that channel). However, the MS shall update 
all the random access parameters on receipt of the new SYSINFO-Q definition (if it is still using the 
SYSINFO-Q default definition on that channel) - including parameters "Timeslot Pointer", "Frame-length 
Factor" and "Minimum PDU Priority". 

NOTE 2: This contrasts with the procedure in clause 23.5.1.4.1 1, in which an MS on an assigned channel does not 
update parameters "Timeslot Pointer", "Frame-length Factor" and "Minimum PDU Priority" on receipt of 
a new SYSINFO definition on that channel. 

The following points may be noted: 

a) The BS may send the response MAC-RESOURCE PDU using any valid combination of modulation level and 
coding rate. 

b) If the MS is attempting random access and receives a MAC-RESOURCE (or MAC-END or MAC-D-BLCK) 
PDU that does not indicate successful random access but grants a reserved subslot or slot(s) for this address 
(seeclause23.5.1.4.9d): 

in the case of a reserved subslot, the MS may use any SCH-Q/HU logical channel appropriate to the 
bandwidth of the channel when it transmits in a reserved capacity; the MS shall not use SCH-Q/RA in 
the reserved subslot; 

in the case of reserved slot(s), the MS may use any SCH-Q/U logical channel appropriate to the 
bandwidth of the channel when it transmits in the reserved capacity. 

c) In the present document, the only usage of QAM channels is for assigned SCCH. Therefore the MS obeys the 
procedures for an MS on an assigned channel as defined in the earlier clauses within clause 23.5.1.4, subject to 
the differences given above. 

23.5.2 Reserved access 

The random access protocol is generally needed when the MS-MAC wishes to initiate a transaction. However, when an 
MS-MAC is required to send a solicited message or when it has further signalling to send after the initial access, the BS 
may reserve slots for that particular MS. Also the MS at SNDCP level may negotiate that the BS will grant reserved 
capacity with a specified repetition period (and specified accuracy), in order to support an application which requires 
regular transmissions of bursts of data; this is called scheduled access. When the schedule becomes active, the BS may 
reserve slots for that MS without the MS needing to use random access (see clause 23.5.2.6 and clause 28). 

The ACCESS-ASSIGN PDU (on the AACH or AACH-Q) indicates which subslots are reserved and therefore not 
available for random access by other MSs. The MS-MAC for which a subslot or slot(s) are reserved is informed on the 
downlink signalling channel, using the MAC -RESOURCE or MAC-END or MAC-D-BLCK PDU. 

This clause describes the MS procedures for requesting reserved slots, and the procedures for granting and using 
reserved slots. 
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23.5.2.1 Reservation requirement 



The MAC-ACCESS, MAC-DATA, MAC-U-BLCK, MAC-END-HU and MAC-END PDUs on the upHnk all allow the 
MS-MAC to indicate its reservation requirement on this control channel: 

• The "reservation requirement" element is an optional element in the MAC-ACCESS, MAC-DATA, 
MAC-END-HU and MAC-END PDUs, and shall not be included unless the MS has further signalling ready to 
send. 

• The "reservation requirement" element is always included in the MAC-U-BLCK PDU. A specific value is 
used in the MAC-U-BLCK PDU when the MS has no further signalling to send. 

If the MS has further signalling to send for this address on this control channel, the MS-MAC shall include the 
"reservation requirement" element whenever it transmits an SCH MAC block (i.e. SCH/HU, SCH-P8/HU, SCH-Q/HU, 
SCH-Q/RA, SCH/F, SCH-P8/F or SCH-Q/U) containing a MAC-ACCESS, MAC-DATA, MAC-U-BLCK, 
MAC-END-HU or MAC-END PDU. If PDU association is used within the MAC block then the "reservation 
requirement" element shall be included in the last (non-null) PDU in the MAC block. 

All MAC-U-BLCK PDUs contain the "reservation requirement" element, irrespective of whether the PDU is sent as the 
last PDU in the MAC block. (The "reservation requirement" element in a MAC-U-BLCK PDU may indicate "no 
reservation requirement".) On a QAM channel, the MAC-U-BLCK PDU is shorter than the MAC block in many cases 
i.e. when using modulation levels higher than 4-QAM or for bandwidths of 100 kHz or more; therefore the "reservation 
requirement" element may be sent more than once in a MAC block. If the "reservation requirement" element is sent 
more than once in a MAC block, each instance of the element shall contain the same information. 

The "reservation requirement" element shall indicate the MS's estimate of the total capacity required for any further 
signalling messages (basic link or advanced link, fully scheduled or unscheduled) that it currently has ready to send for 
this individual address on this control channel: 

• The method for the MS-MAC to calculate the required capacity for a fragmented message is described in 
clause 23.4.2.1.2. The required number of slots depends on the modulation, and the bandwidth and coding rate 
for QAM, to be used for sending the fragmented message. 

• The required capacity for other signalling ready to send on a 7i/4-DQPSK channel is known from the "amount 
of data in LLC buffer" parameter in the DATA-IN-BUFFER signal received from the LLC. 

• The required capacity for other signalling ready to send on a D8PSK or QAM channel shall be estimated from 
the information about the amount of data in the LLC buffer per data category, provided in the 
DATA-IN-BUFFER signal received from the LLC. The required number of slots to send the data depends on 
both the amount of data and the modulation level (and coding rate for QAM) with which the MS -MAC 
currently expects to send the data. If there is data for more than one data category, the expected modulation 
level (and coding rate for QAM) may be different for the different data categories; in this case, the MS-MAC 
shall estimate the number of slots required at each modulation level (and coding rate for QAM) and shall 
indicate the total in the "reservation requirement"; see also clause 23.4.9. 

NOTE 1 : The reservation requirement indicates the total amount of C-plane signalling that the MS wishes to send 
for this address, irrespective of whether or not the MS has already been granted some future slots. 

NOTE 2: The reservation requirement procedure applies only to signalling messages to be sent with an individual 
address, i.e. the MS's ISSI/ASSI, USSI, SMI or corresponding event label. The BS grants a subslot or 
slot(s) for the group address when it invokes a low level group presence indication, so the reservation 
requirement procedure does not apply to group addresses. 

NOTE 3: When the MS indicates its reservation requirement, it indicates only the required capacity for the address 
with which the reservation requirement is sent. The ISSI and its associated ASSI are regarded as 
equivalent for the purposes of this procedure. Similarly, an event label and its corresponding address are 
regarded as equivalent for the purposes of this procedure. However, an MS is not permitted to combine 
any reservation requirements for its SMI with requirements for an SSI (or vice versa), and it is not 
permitted to combine the reservation requirements for multiple TSI families. 
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The MS-MAC may indicate a reservation requirement of one subslot, or one or more full slots (as shown in clause 21). 
The required number of slots is coded in a non-linear format. If the MS's requirement cannot be represented exactly 
within the defined format, the MS-MAC shall round down to the next lower valid number of slots, except possibly in 
the case of a MAC- ACCESS or MAC-DATA PDU containing the start of fragmentation. In the case of the start of 
fragmentation, the reservation requirement shall cover at least the capacity needed for the remainder of the fragmented 
message. 

NOTE 4: The above exception is needed for fragmented messages because the MAC-FRAG PDU cannot include a 
"reservation requirement" element. Therefore: 

a) if the MS needs 7 slots to send the rest of the TM-SDU, it asks for 8 slots (or more if it has other 
signalling to send); or 

b) if it needs 9 slots to send the rest of the TM-SDU, it asks for 10 slots (or more); or 

c) if it needs 1 1 or 12 slots to send the rest of the TM-SDU, it asks for 13 slots (or more); or 

d) if it needs 14 or 15 slots to send the rest of the TM-SDU, it asks for 17 slots (or more). 

In all other cases, the "rounding down" rule applies. 

Case a) may apply when using 7i/4-DQPSK or 71/8-D8PSK modulation, or 4-QAM rate='/2 on a 25 or 
50 kHz channel, or 16-QAM rate='/2 on a 25 kHz channel; case b) may apply when using 7i/4-DQPSK, or 
4-QAM rate='/2 on a 25 kHz channel; cases c) and d) may apply when using 4-QAM rate='/2 on a 25 kHz 
channel; see clause 23.4.2.1.2. 

23.5.2.2 Slot granting 
23.5.2.2.1 General 

The BS may allocate reserved slots to an MS either: 

a) after receiving a request for reserved capacity from the MS; or 

b) when the BS sends the MS a message that requires a response; or 

c) as a result of an active schedule negotiated by the SNDCP (see clause 23.5.2.6 and clause 28). 

The BS shall perform the allocation by including either the "basic slot granting" element or the "multiple slot granting" 
element in a MAC -RESOURCE or MAC-END PDU sent to the MS, or by including the "basic slot granting" element 
in a MAC-D-BLCK PDU sent to the MS. The "basic slot granting" and "multiple slot granting" elements are optional 
elements, included only when required. 

In case b), the "basic slot granting" or "multiple slot granting" element will generally be included in the same downlink 
PDU as the invoking message. For a fragmented downlink TM-SDU, the grant may be included in either the 
MAC-RESOURCE or the MAC-END PDU. 

For the MAC -RESOURCE or MAC-D-BLCK PDU, the slot grant shall refer to the MS addressed in the MAC header. 
For the MAC -END PDU, the slot grant shall refer to the MS receiving the fragmented message (addressed in the 
MAC-RESOURCE PDU that contained the first fragment). 

There are two forms of the slot granting mechanism: basic slot granting and multiple slot granting: 



• 



• 



Basic slot granting may be used on a 7i/4-DQPSK, D8PSK or QAM channel. It allows the BS to grant a single 
subslot, or a single slot, or several slots occupying successive slots on this uplink control channel (except that 
the MS shall jump over those slots in frame 18 that contain predefined common linearization opportunities). 

Multiple slot granting is available only on a QAM channel. It allows the BS to grant disjoint resources with 
one slot grant by including multiple explicit instances of the "basic slot granting" element and/or by implicit 
repetition of the "basic slot granting" element. 
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23.5.2.2.2 Basic slot granting 



The "basic slot granting" element shall be sent by the BS, and understood by the receiving MS-MAC, in the format 
shown in clause 21. It shall consist of two sub-elements: 

1) Capacity allocation: 

This element shall indicate the amount of reserved capacity that is granted on the uplink channel. It may 
indicate either a single subslot or one or more full slots. For a subslot grant, the "capacity allocation" element 
shall indicate whether the MS shall use the first or second subslot. 

2) Granting delay: 

This element shall indicate the time of the start of the reservation. It shall have one of the following forms: 

Start in the next uplink slot on this channel (granting delay = OOOO2). For both single-slot and multi-slot 
channels, this shall refer to the same-numbered uplink timeslot as the slot containing the slot grant, in the 
same TDM A frame. 

Delay for the specified number of delay opportunities on this uplink channel (granting delay = 0001 2 to 
1 IOI2). When counting delay opportunities, the MS shall count successive slots on this uplink channel 
(including those slots in frame 18 that contain predefined common linearization opportunities). So, for a 
single-slot channel, the granting delay indicates the delay in TDMA frames; whereas, for a multi-slot 
channel, there are two or more delay opportunities per TDMA frame (as indicated by the "Timeslot 
Assigned" element from the MAC-RESOURCE or MAC-END PDU that allocated the channel). 

Start in the first uplink opportunity in the next frame 18 (granting delay =11 IO2). For a slot grant sent in 
frame 18, this shall refer to the following frame 18 (after this one). 

Wait for another slot grant (granting delay =111 12). This form does not actually grant slots at this time, 
but shall serve to restart the MS's timer T.206, thereby preventing the MS-MAC from reverting to 
random access. 

After any granting delay, a grant for one subslot or slot shall apply to the next slot on this uplink channel. For a subslot 
grant, the "capacity allocation" element shall indicate whether the MS shall use the first or second subslot. 

NOTE: For a grant of a first subslot or a full slot, it is the responsibility of the BS not to send a granting delay 
which indicates that the granted capacity is in an uplink slot in frame 18 corresponding to one of the 
predefined common linearization opportunities. This applies also to the first slot of a grant of more than 
one slot. If an MS receives a slot granting PDU that does not conform to this limitation then it should 
ignore the slot grant. 

However, the BS may grant the second subslot for reserved access in an uplink slot in frame 18 
corresponding to one of the predefined common linearization opportunities. 

When several slots are granted, these shall occupy successive slots on this uplink channel (after any granting delay) 
except that the MS shall jump over those slots in frame 18 that contain predefined common linearization opportunities. 
As defined in clause 9 and clause 23.4.5, predefined common linearization opportunities in frame 18 occur: 

• on a 7I/4-DQPSK or D8PSK channel: when (MN + TN) mod 4 = 3; 



• 



on a QAM assigned channel: when (MN + TN) mod 4 = 3 and TN is the lowest numbered timeslot of 
the allocated channel. 



If the MS-MAC receives more than one slot grant for an individual address or valid event label, it shall assume that its 
current allocation is the combination (i.e. union) of slot grants on this control channel. 

Capacity that has been granted cannot be withdrawn by the BS. However, if the MS indicates that it has no further 
signalling to send then, in some cases, the BS may re-use any remaining granted capacity for another MS (see 
clause 23.5.2.3.1 for details of when the MS does not use the remainder of the allocation). 
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23.5.2.2.3 Multiple slot granting 



Multiple slot granting is available only on a QAM channel. It allows the BS to grant disjoint resources with one slot 
grant by including multiple explicit instances of the "basic slot granting" element and/or by implicit repetition of the 
"basic slot granting" element: 

• it allows multiple instances of the "basic slot granting" element to be included in one slot grant; 

• it also provides an implicit repeat mechanism for each instance of the "basic slot granting" element, to allow a 
patterned repetition of resources to be granted with one "basic slot granting" element. 

The "multiple slot granting" element shall be sent by the BS, and understood by the receiving MS-MAC, in the format 
shown in clause 21. The "multiple slot granting" element contains a number (1 to 7) of slot granting sets where each set 
comprises: 

• an 8-bit "basic slot granting" element; and 

• a 4-bit implicit repeat count (IRC) for this "basic slot granting" element. 

The receiving MS-MAC shall regard each slot granting set as if it had received (IRC + I) instances of the 8-bit "basic 
slot granting" element. 

EXAMPLE: For a multiple slot grant comprising two slot granting sets, where the first slot granting set 

included an implicit repeat count of 3 and the second slot granting set included an implicit repeat 
count of 2, the MS regards the multiple slot grant as if it had received 7 basic slot granting 
elements in the following order: 

first basic slot granting element; 

implicit repetition of first basic slot granting element; 

implicit repetition of first basic slot granting element; 

implicit repetition of first basic slot granting element; 

second basic slot granting element; 

implicit repetition of second basic slot granting element; 

implicit repetition of second basic slot granting element. 

The MS-MAC shall process each of the basic slot granting elements (either included explicitly or implied by the 
implicit repeat count). As in clause 23.5.2.2.2, the basic slot granting element shall consist of two sub-elements: 

1) Capacity allocation: 

This element shall indicate the amount of reserved capacity that is granted on the uplink channel. It may 
indicate either a single subslot or one or more full slots. For a subslot grant, the "capacity allocation" element 
shall indicate whether the MS shall use the first or second subslot. 

2) Granting delay: 

This element shall indicate the time of the start of the reservation. 
Use of granting delay = 11 II2 is not valid in a multiple slot grant. 

The granting delay in the first basic slot granting element shall be counted from the downlink slot containing 
the slot grant, as defined in clause 23.5.2.2.2. 
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The granting delay in the second and subsequent implicit or explicit basic slot granting elements (including 
implicit repetitions of the first basic slot granting element) shall be counted from the end of the grant defined 
by the previous implicit or explicit basic slot granting element. The granting delay shall have one of the 
following forms: 

a) Start in the next uplink slot on this channel (granting delay = OOOO2). For both single-slot and multi-slot 
channels, this shall refer to the next uplink timeslot on this uplink channel following the end of the 
previous slot grant. 

b) Delay for the specified number of delay opportunities on this uplink channel (granting delay = 0001 2 to 
1 IOI2). When counting delay opportunities, the MS shall count successive slots on this uplink channel 
(including those slots in frame 18 that contain predefined common linearization opportunities). 

c) Start in the first uplink opportunity in the next frame 18 (granting delay =11 IO2). If last slot or subslot of 
the previous slot grant was in frame 18, this shall refer to the following frame 18 (after this one). 

After any granting delay, the start of the grant shall apply to the defined slot on this uplink channel with the following 
exceptions in cases a), b) and c). For a grant of a first subslot or a full slot, if the granting delay nominally indicates that 
the granted capacity is in an uplink slot in frame 18 corresponding to one of the predefined common linearization 
opportunities, the MS shall regard the slot grant as being in the following slot on this uplink channel. Similarly, for a 
grant of more than one slot, if the granting delay nominally indicates that the granted capacity starts in an uplink slot in 
frame 18 corresponding to one of the predefined common linearization opportunities, the MS shall regard the slot grant 
as starting in the following slot on this uplink channel. 

NOTE 1 : This exception does not apply for a grant of the second subslot in a slot for reserved access. 

NOTE 2: This exception applies only for second and subsequent implicit or explicit basic slot granting elements 
(including implicit repetitions of the first slot granting element). For the granting delay in the first basic 
slot granting element, if granting a first subslot or a full slot, it is the responsibility of the BS not to send a 
granting delay which indicates that the granted capacity is in an uplink slot in frame 18 corresponding to 
one of the predefined common linearization opportunities. This applies also to the first slot of a grant of 
more than one slot. If an MS receives a slot granting PDU that does not conform to this limitation then it 
should ignore the entire multiple slot grant. 

When several slots are granted, these shall occupy successive slots on this uplink channel (after any granting delay) 
except that the MS shall jump over those slots in frame 18 that contain predefined common linearization opportunities. 

If the MS-MAC receives more than one slot grant for an individual address or valid event label, it shall assume that its 
current allocation is the combination (i.e. union) of slot grants - either basic slot grants or multiple slot grants - on this 
control channel. 

Capacity that has been granted cannot be withdrawn by the BS. However, if the MS indicates that it has no further 
signalling to send then, in some cases, the BS may re-use any remaining granted capacity for another MS (see 
clause 23.5.2.3.1 for details of when the MS does not use the remainder of the allocation). 

23.5.2.2.4 Slot granting in normal mode 

On the MCCH, the uplink for reserved access shall occupy only slot 1 of the main carrier. For a capacity allocation of 
more than one slot, this refers to the use of successive slot I's except that the MS shall jump over those slots in frame 18 
that contain predefined common linearization opportunities. 

EXAMPLE 1: A three-slot granted allocation starting in slot 1 of frame 8 occupies also slot 1 of frames 9 and 10; 
a four-slot granted allocation starting in slot 1 of frame 16 of multiframe 2 occupies also slot 1 of 
frames 17, 1 and 2. 

For a common SCCH, the same rule shall apply, except with the appropriate slot number on the main carrier. 

For an assigned SCCH or for an ACCH, the uplink for reserved access shall occupy the timeslot(s) per TDMA frame 
indicated in the "Timeslot Assigned" element from the MAC -RESOURCE or MAC -END PDU that allocated the 
channel except that the MS shall jump over those slots in frame 18 that contain predefined common linearization 
opportunities. 
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EXAMPLE 2: For an assigned SCCH using timeslots 3 and 4: 

a four-slot granted allocation starting in slot 4 of frame 10 occupies also slots 3 and 4 of 
frame 11 and slot 3 of frame 12; 

on a 3I/4-DQPSK or D8PSK channel, a six-slot granted allocation starting in slot 3 of 

frame 17 of multiframe 3 occupies also slot 4 of frame 17, slot 3 of frame 18, slots 3 and 4 of 

frame 1 and slot 3 of frame 2; 

on a QAM channel, a six-slot granted allocation starting in slot 3 of frame 17 of multiframe 3 
occupies also slot 4 of frame 17, slots 3 and 4 of frame 18 and slots 3 and 4 of frame 1; 

on a QAM channel, a six-slot granted allocation starting in slot 3 of frame 17 of multiframe 4 
occupies also slot 4 of frame 17, slot 4 of frame 18, slots 3 and 4 of frame 1 and slot 3 of 
frame 2. 

The granting delay is given in terms of the number of opportunities for reserved access on this channel except that, 
when counting slots for the granting delay, the MS shall include those slots in frame 18 that contain predefined common 
linearization opportunities. So, for a single-slot channel, the granting delay indicates the delay in TDMA frames; 
whereas, for a multi-slot channel, there are two or more opportunities per TDMA frame. 

EXAMPLE 3: On the MCCH, for a slot grant sent in frame 15 with a granting delay of OIOO2 (i.e. 4 opportunities 
delay), the granted capacity starts in slot 1 of frame 1 irrespective of the multiframe number. On an 
assigned SCCH using timeslots 1 and 2, for a slot grant sent in slot 2 of frame 4 with a granting 
delay of OIOI2 (i.e. 5 opportunities delay), the granted capacity starts in slot 1 of frame 7. 

NOTE 1 : The width of the uplink channel for reserved access is the same as the width of the downlink channel. It is 
defined independently of any extension of the uplink channel for random access. 

NOTE 2: The counting of slots for the granting delay is defined in absolute terms given the known number of 
timeslots per TDMA frame for this channel (and the predefined mapping of common linearization 
opportunities in frame 18 for a multiple slot grant after the first granting delay). The use of granted slots 
by the MS is defined in absolute terms given the known number of timeslots per TDMA frame for this 
channel and the predefined mapping of common linearization opportunities in frame 18. The MS 
transmits in the granted slots without needing to check the ACCESS-ASSIGN PDU. 

For example, on a channel assigned for traffic, the MS should follow the normal methods for counting 
slots for the granting delay and for using reserved slots. It is the responsibility of the BS to avoid granting 
slots where another MS may be transmitting traffic. Therefore, when the uplink is in SACCH so that only 
frame 18 is available for reserved access, the BS should grant only one reserved subslot or slot at a time. 
(The BS should use either granting delay = OOOO2 or 1 1 IO2 when sending the slot grant in downlink 
frame 18 since, for example, if it were to use granting delay = 0001 2, the MS would regard this as an 
instruction to transmit in frame 1.) 

For a basic slot grant or the first basic slot grant in a multiple slot grant, the BS should not grant the first 
subslot or a first full slot in a frame 18 slot that corresponds to one of the predefined common 
linearization opportunities. It is also the responsibility of the BS to avoid assigning common linearization 
subslots in frames 1 to 17 in positions that coincide with granted slots. 

Multiple slot granting may be used on a QAM channel (as described in clause 23.5.2.2.3). 

EXAMPLE 4: On a QAM channel using timeslots 2, 3 and 4: for a multiple slot grant sent in slot 4 of frame 1 1 of 
multiframe 9 and comprising two slot granting sets, where: 

the first slot granting set granted a capacity allocation of two slots with a granting delay of 
OOOI2 (i.e. 1 opportunity delay) and an implicit repeat count of 3; and 

the second slot granting set granted a capacity allocation of five slots with a granting delay of 
OIOO2 (i.e. 4 opportunities delay) and an implicit repeat count of 0, 

the granted allocation comprises slots 2 and 3 of frames 12, 13, 14 and 15, slots 2, 3 and 4 of 
frame 17 and slots 3 and 4 of frame 18 of the current multiframe. 
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EXAMPLE 5: On a 4-slot QAM channel: for a multiple slot grant sent in slot 2 of frame 3 of any multiframe and 
comprising three slot granting sets, where: 

the first slot granting set granted a capacity allocation of one slot with a granting delay of 
OOOO2 and an implicit repeat count of 0; and 

the second and third slot granting sets each granted a capacity allocation of one slot with a 
granting delay of 001 12 (i.e. 3 opportunities delay) and an implicit repeat count of 15, 

the granted allocation comprises slot 2 of frames 3 to 18 of the current multiframe and slot 2 of 
frames 1 to 17 of the next multiframe. 

EXAMPLE 6: On a 4-slot QAM channel: for a multiple slot grant sent in slot 2 of frame 11 of multiframe 6 and 
comprising one slot granting set granting a capacity allocation of one slot with a granting delay of 
001 12 (i.e. 3 opportunities delay) and an implicit repeat count of 12, the granted allocation 

comprises slot 1 of frames 12 to 17 of multiframe 6, slot 2 of frame 18 of multiframe 6 and slot 2 
of frames 1 to 6 of multiframe 7. (If the BS wishes the MS to revert back to use of slot 1 after the 
predefined linearization opportunity, it would need to use more slot granting sets.) 

23.5.2.2.5 Slot granting in minimum mode 

During minimum mode, if the BS sends a slot granting PDU in an MS's designated minimum mode frame 18 slot, and if 
that slot is slot 2, 3 or 4, then the BS shall grant only one reserved subslot or slot in that PDU. The reserved subslot or 
slot shall be granted either in the corresponding uplink slot of that frame 18 (Granting delay = OOOO2) or in the 
corresponding uplink slot of the following frame 18 (Granting delay =11 IO2). 

If an MS in minimum mode receives a slot granting PDU in slot 2, 3 or 4 of frame 18 that does not conform to the 
above limitations, then it shall ignore the slot grant. 

NOTE 1: The above limitations apply only to those MSs that are in common control mode, having been receiving 
the MCCH. They do not apply to MSs on an assigned channel that are using slot 2, 3 or 4 of frame 18 
within their ACCH. 

NOTE 2: The BS should not grant the first subslot or a full slot in a frame 18 slot that corresponds to one of the 
predefined common linearization opportunities. 

For a slot grant sent in slot 1 of frames 1 to 17, or in slot 1 of frame 18, the BS may make a capacity allocation of more 
than one slot; this shall then refer to the use of successive uplink slot I's except that the MS shall jump over those slots 
in frame 18 that contain predefined common linearization opportunities (i.e. the normal method). 

NOTE 3: Multiple slot granting does not apply on a 7i/4-DQPSK channel. Therefore only basic slot granting is 
appropriate in minimum mode. 

23.5.2.2.6 Slot granting on time-shared control channel 

On a time-shared MCCH, the BS may send a slot granting PDU either in one of its own reserved frames or in a 
common frame. It may grant single subslots, or one or more full slots. 

The delay opportunities for counting the granting delay comprise the combination of: 

a) slot 1 of the reserved frames for this BS; and 

b) slot 1 of the common frames. 

So the MS shall count successive slot I's, except that it shall jump over frames that are neither reserved for this BS nor 
common. 
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The opportunities for reserved access for using a grant of more than one slot comprise the combination of: 

a) slot 1 of the reserved frames for this BS; and 

b) slot 1 of the common frames, 

except that the MS shall jump over those slots in frame 18 for which (MN + TN) mod 4 = 3. So the MS shall use 
successive slot I's, except that it shall jump over frames that are neither reserved for this BS nor common and shall 
jump over those slots in frame 18 for which (MN + TN) mod 4 = 3. 

For a time-shared common SCCH, "slot 1" in the above procedure shall be replaced by the appropriate slot number on 
the main carrier. 

NOTE 1 : The network is responsible for co-ordinating the use of the uplink on time-sharing cells, to avoid 
collisions in granted slots. 

NOTE 2: Multiple slot granting does not apply on a 3i/4-DQPSK channel. Therefore only basic slot granting is 
appropriate on a time-shared control channel. 

23.5.2.2.7 BS slot granting operation 

The BS may use the facilities for slot granting defined above. 

After granting a subslot or slots, the BS should mark the equivalent uplink subslots as "reserved" in the 
ACCESS-ASSIGN PDU, thereby preventing other MS from sending random accesses. For example, after granting one 
slot, the BS should mark the two equivalent uplink subslots as "reserved". 

If the BS does not receive a message in an individually granted subslot or slot, this may be either because the MS did 
not receive the downlink message or because the uplink message was corrupted during propagation. The BS may decide 
to send another slot granting PDU to the MS. In particular, if the BS does not receive a message in the first slot of a 
grant of several slots, or for a multiple slot grant, it is recommended that the BS sends another slot granting PDU 
re-granting the remainder of the slots to the same MS (and further slots if appropriate). 

For slot granting PDUs, as for all downlink PDUs, the BS should take account of any energy economy or napping or 
dual watch operation in the MS, sending the PDU in a slot where the MS should be listening. 

When the BS allocates reserved slots on a 7i/4-DQPSK multi-slot Packet Data Channel (PDCH), it may use the 
information on the MS capabilities from the SNDCP's "resource request" element if provided (see clause 28) when 
deciding on the amount of reserved capacity to allocate in one slot grant. 

If the BS wishes to send data to a group, with a low level presence indication from recipient MSs, the BS shall include 
the group address and a basic slot grant in the MAC PDU that contains the invoking BL-DATA message. The slot grant 
may be for one subslot, or optionally for one or more full slots, though each MS in the group will use only one subslot; 
see clause 23.5.2.3.2. The methods whereby the BS detects transmission in the granted subslot (or slots) are left open 
for choice by system designers, e.g. measurement of received signal strength. 

NOTE: Multiple slot granting is not appropriate for the low level presence indication. 

The BS may use basic slot granting on a 7i/4-DQPSK, D8PSK or QAM channel. This allows the BS to grant a single 
subslot, or a single slot, or several slots occupying successive slots on this uplink control channel (except that the MS 
jumps over those slots in frame 18 that contain predefined common linearization opportunities). 

The BS may use multiple slot granting on a QAM channel. As described in clause 23.5.2.2.3, this allows the BS to grant 
disjoint resources with one slot grant by including multiple explicit instances of the "basic slot granting" element and/or 
by using an implicit repeat mechanism for each instance of the "basic slot granting" element. 

The implicit repeat mechanism allows a patterned repetition of resources to be granted with one "basic slot granting" 
element. For example, this may be useful for allocating resources to an MS using scheduled access with a fairly short 
schedule repetition period (i.e. within the range of the "granting delay" element), or for allocating resources to other 
MSs sharing the channel with an MS that is using scheduled access. 

Use of multiple explicit instances of the "basic slot granting" element may be useful for providing disjoint slot grants 
that are not based on a patterned repetition of resources. 
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Use of multiple explicit instances of the "basic slot granting" element in combination with the implicit repeat 
mechanism may be useful in some cases, for example: at the beginning of a patterned repetition of resources in order to 
be able to specify a different granting delay for the first capacity allocation, or to extend the effective length of the 
patterned repetition. It may also be useful if the BS wishes to regain the exact synchronization of a patterned repetition 
of resources after a predefined common linearization opportunity. 

If the MS is not frequency full duplex and does not have fast switching capability, and is operating on a multi-slot 
channel, it cannot receive the downlink assigned channel during the elapse time corresponding to one capacity 
allocation. Similarly, if the MS is not frequency full duplex but does have fast switching capability, and is operating on 
a four-slot channel or a two-slot channel with alternating timeslots (i.e. slots 1 and 3 or slots 2 and 4), it cannot receive 
the downlink assigned channel during the elapse time corresponding to one capacity allocation. (For multiple slot 
granting, the MS can receive the downlink assigned channel between each instance of capacity allocation for 
appropriate values of the granting delay.) If the MS cannot receive the downlink assigned channel during the elapse 
time corresponding to a capacity allocation, it cannot receive L2-LINK-FEEDBACK-INFO messages or 
acknowledgement bit maps from the BS, or make measurements of the downlink assigned channel, during the elapse 
time corresponding to that capacity allocation; this may affect the MS's link adaptation procedures on a D8PSK or 
QAM channel (see clause 23.4.9.2). When appropriate, the BS may choose to limit the size of each instance of the 
capacity allocation on a multi-slot D8PSK or QAM channel. This may apply particularly when the BS perceives that the 
quality of the link is currently variable such that the MS may wish to adapt its bit rate more frequently than the 
maximum length of capacity allocation. 

23.5.2.3 Use of reserved slots 

23.5.2.3.1 Individual address or event label 

If an MS receives a MAC-RESOURCE PDU or MAC-END PDU containing a "basic slot granting" or "multiple slot 
granting" element for one of its individual addresses (i.e. its ISSI, ASSI, USSI or SMI) or for a valid individual event 
label for this control channel, the MS-MAC shall perform the following actions relating to the "basic slot granting" or 
"multiple slot granting" element; if an MS receives a MAC-D-BLCK PDU containing a "basic slot granting" element 
for one of its individual addresses or for a valid individual event label for this control channel, the MS-MAC shall 
perform the following actions relating to the "basic slot granting" element. Other actions may be performed relating to 
other elements in the MAC header. 

For a basic slot grant, the MS-MAC shall inspect the "capacity allocation" and "granting delay" elements and shall 
record which subslot or slot(s) are allocated to it, as described in clause 23.5.2.2. For a multiple slot grant, the 
MS-MAC shall inspect the "number of slot granting sets" element, the "capacity allocation" and "granting delay" 
elements in each "basic slot granting" element and the "implicit repeat count" element(s) and shall record which 
subslots and/or slots are allocated to it, as described in clause 23.5.2.2. 

If the MS has signalling messages to send for this address on this control channel, as known from the 
DATA-IN -BUFFER signal, then the following procedure applies for each allocated subslot or slot: 

• For an allocated subslot, the MS-MAC shall use the appropriate logical channel (SCH/HU on a 3i/4-DQPSK 
channel, SCH/HU or SCH-P8/HU on a D8PSK channel, SCH-Q/HU on a QAM channel); it shall send the 
final fragment of a fragmented TM-SDU, or otherwise a message from the LLC (or messages by association), 
except in the following case. If the MS has signalling to send but cannot use a subslot, e.g. if it has only 
full-slot advanced Hnk messages to send, then the MS-MAC shall send a MAC-ACCESS PDU containing the 
"reservation requirement" element and no TM-SDU. 

• For an allocated slot, the MS-MAC shall use the appropriate logical channel (SCH/F on a 7i/4-DQPSK 
channel, SCH/F or SCH-P8/F on a D8PSK channel, SCH-Q/U on a QAM channel; it shall send the next 
fragment of a fragmented TM-SDU, or otherwise a message from the LLC (or messages by association). 

After transmitting a complete TM-SDU, or a final fragment, the MS-MAC shall report to the LLC that the message has 
been sent by reserved access (using the TMA-REPORT indication primitive). 

If the MS has no signalling message to send for this address on this control channel then: 

• if the MS is on a 7i/4-DQPSK or D8PSK channel, the MS-MAC should send the Null PDU in the allocated 
subslot or slot; 



£75/ 



818 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



• if the MS is on a QAM channel, the MS-MAC shall send either: 

a) the Null PDU in the allocated subslot or slot; or 

b) a dummy MAC-ACCESS or MAC -DATA PDU in the allocated subslot or slot i.e. a PDU containing no 
TM-SDU; the dummy PDU shall be followed by a Null PDU sent by association (except in the case of 
logical channel SCH-Q/HU25-4H). 

On a 7I/4-DQPSK or D8PSK channel, after sending: 

• the Null PDU in an SCH/HU, SCH-P8/HU, SCH/F or SCH-P8/F MAC block; or 

• any SCH/HU or SCH-P8/HU MAC block that does not include a "reservation requirement" element; or 

• any SCH/F or SCH-P8/F MAC block that contains: 

a MAC-DATA or MAC-END PDU, and does not include a "reservation requirement" element; or 

a MAC-U-BLCK PDU indicating no reservation requirement, 

the MS shall not use any other capacity that has already been granted for this address on this control channel (whether 
in one slot granting PDU, or more than one). If the MS receives a further slot granting PDU, and if it still has no 
signalling messages to send for this address, then it shall send the Null PDU in the first allocated slot or in the allocated 
subslot, and shall not use the remainder of the allocation. 

On a QAM channel, after sending the Null PDU as the only PDU in an SCH-Q/HU or SCH-Q/F MAC block, the MS 
shall not use any other capacity that has already been granted for this address on this control channel (whether in one 
slot granting PDU, or more than one, and by either basic slot granting or multiple slot granting). If the MS receives a 
further slot granting PDU, and if it still has no signalling messages to send for this address, then it may send the Null 
PDU as the only PDU in the first allocated slot or subslot; if it transmits the Null PDU as the only PDU in the MAC 
block then it shall not use the remainder of the allocation. 

NOTE 1 : Therefore, in case a) above, the MS is not permitted to use any other capacity that has already been 

granted for this address on this control channel. In case b), the MS may use any other capacity that has 
already been granted for this address on this control channel. 

NOTE 2: The ISSI and its associated ASSI are equivalent for the purposes of use of reserved slots (so the MS may 
use any subslot or slot(s) granted on its ISSI for messages sent with its ASSI, or vice versa). Similarly, an 
event label and its corresponding address are equivalent for the purposes of use of reserved slots. 

Also, a newly assigned ASSI is equivalent to the replaced ASSI or USSI for the purposes of use of 
reserved slots. Thus, if an MS receives a slot grant on its ASSI then it may use the subslot or slot(s) for 
messages sent using a new ASSI which replaces that ASSI; and, if a migrating MS receives a slot grant 
on its USSI while that USSI is still valid then it may use the subslot or slot(s) for messages sent with its 
ASSI. 

However, an MS is not permitted to use a subslot or slot(s) granted on an SSI for messages to be sent with 
its SMI, or vice versa; also, it is not permitted to use a subslot or slot(s) granted on one SSI for an SSI 
from another TSI family. These restrictions may possibly be relaxed in future editions of the present 
document in the case of the final slot of an MS's requested reserved capacity. 

NOTE 3: As defined above, a migrating MS that receives a slot grant on its USSI while that USSI is still valid may 
use the subslot or slot(s) for messages sent with its ASSI. However, there is possible contention on 
capacity granted on the USSI if multiple migrating MSs with the same USSI are trying to register at the 
same time. Therefore, when assigning the ASSI, the BS may prefer not to allocate more than one reserved 
slot on the USSI. This is because any continuation or final fragments of an uplink message sent with the 
ASSI do not contain addressing information. 
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23.5.2.3.2 Group address 



If an MS receives a MAC-RESOURCE PDU or MAC -END PDU or MAC-D-BLCK PDU containing a "basic slot 
granting" element for one of its valid group addresses, the MS-MAC shall perform the following actions relating to the 
"basic slot granting" element. Other actions may be performed relating to other elements in the MAC header. 

The MS-MAC shall inspect the "capacity allocation" and "granting delay" elements and shall note which subslot or 
slot(s) are allocated, as described in clause 23.5.2.2. If the MS has a signalling message with this group address to send 
on this control channel then it shall transmit the message in an uplink subslot using the MAC-ACCESS PDU: 

a) for a subslot grant, it shall use the allocated subslot; 

b) for a grant of one or more slots (G slots), it shall choose one subslot randomly from the grant, i.e. random 
choice between 1 and 2 x G using a uniform distribution. 

Otherwise, the MS shall not transmit. 

NOTE: This procedure is used only for the low level group presence indication (see clauses 22.2.1.3 and 
22.3.1.2). 

23.5.2.4 Reverting to random access 

23.5.2.4.1 Reverting to random access for unscheduled signalling messages 

If the following criteria are all satisfied then the MS-MAC may initiate the random access procedure (see 
clause 23.5.1): 

a) the MS-MAC has sent a PDU (MAC-ACCESS, MAC-DATA, MAC-U-BLCK, MAC-END-HU or 
MAC -END) indicating a reservation requirement for this address on this control channel; and 

b) the MS-MAC does not currently have any capacity granted for this address on this control channel; and 

c) a time T.206 has elapsed since: 

the MS-MAC last sent a PDU on this control channel for this address (i.e. either a MAC-ACCESS, 
MAC-DATA or MAC-U-BLCK PDU with this address or a MAC-FRAG, MAC-END or 
MAC-END-HU PDU relating to this address); or 

the MS -MAC last received a basic slot granting element for this address on this control channel 
containing the instruction to "Wait for another Slot Grant"; 

whichever is the later; and 

d) the MS still has unscheduled signalling messages to send for this address on this control channel (as indicated 
by the DATA-IN-BUFFER signal). 

The random access request shall be sent on SCH/HU (for a 7i/4-DQPSK or D8PSK channel) or on SCH-Q/RA (for a 
QAM channel) using the MAC- ACCESS PDU, containing a TM-SDU if appropriate. If the MS has any further 
signalling ready to send for this address on this control channel, the MS-MAC shall include a request for reserved 
capacity ("reservation requirement" element) in the MAC-ACCESS PDU. 

NOTE 1 : T.206 is greater than, or equal to, the fragmentation time-out constant T.202. Then, at the time of 
reverting to random access, the MS-MAC will not be in the process of an uplink fragmentation. 

NOTE 2: Time T.206 is counted in downlink signalling opportunities (see annex B). So, for example, in minimum 
mode the absolute time is 18 times its normal value. 
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23.5.2.4.2 Reverting to random access for fully scheduled signalling messages 

When the MS has fully scheduled signalling messages to send, as indicated by the DATA-IN-BUFFER signal from the 
LLC, the MS-MAC may initiate the random access procedure if it: 

a) does not currently have any capacity granted for this address on this control channel; and 

b) a time T has elapsed since the MS-MAC last sent a PDU on this control channel for this address (i.e. either a 
MAC-ACCESS, MAC-DATA or MAC-U-BLCK PDU with this address or a MAC-FRAG, MAC-END or 
MAC-END-HU PDU relating to this address), where T is defined by: 

T = Max ( LMSI, T.227 ) 

where: 

LMSI is the lowest value of the maximum schedule interval for the fully scheduled data to be sent for 
this address on this channel (as indicated by the DATA-IN-BUFFER signal from the LLC); and 

T.227 is the value of the minimum scheduled access waiting time-out (see annex B). 

The random access request shall be sent on SCH/HU (for a 7t/4-DQPSK or D8PSK channel) or on SCH-Q/RA (for a 
QAM channel) using the MAC- ACCESS PDU, containing a TM-SDU if appropriate. If the MS has any further 
signalling ready to send for this address on this control channel, the MS-MAC shall include a request for reserved 
capacity ("reservation requirement" element) in the MAC-ACCESS PDU. 

NOTE 1 : If the MS has both fully scheduled and unscheduled signalling messages to send, it may initiate the 
random access procedure if the criteria in either this clause or clause 23.5.2.4.1 are satisfied. 

NOTE 2: If the MS was in the process of sending a fragmented message at the time when it decides to initiate the 

random access procedure, it should discard the partially sent TM-SDU. (Alternatively the MS may choose 
not to initiate the random access procedure in this case.) 

23.5.2.5 Example of reservation process 

This clause gives an example of the reservation process on a 7i/4-DQPSK channel. 

The MS-MAC has received a TMA-UNITDATA request primitive from the LLC, containing a long TM-SDU (length 
512 bits). It uses a MAC- ACCESS PDU for the random access, including the first 56 bits of the TM-SDU and 
indicating a "reservation requirement" of two slots. The BS sends a MAC-RESOURCE PDU to acknowledge the 
random access request. The MAC-RESOURCE PDU also includes a "basic slot granting" element, granting the two 
required slots. The MS-MAC then sends the remainder of the TM-SDU in one MAC -FRAG PDU (264 bits of 
TM-SDU) and the MAC-END PDU (final 192 bits). The MS has no further signalling to send for this address, so the 
MAC-END PDU does not contain the "reservation requirement" element, and the MAC block is completed with the 
Null PDU and fill bits. 

23.5.2.6 Scheduled access 
23.5.2.6.1 General 

The scheduled access mechanism is provided to support applications which require regular transmissions of bursts of 
data, such as some types of real-time class and telemetry class data. 

The MS at SNDCP level negotiates that the BS will grant a number of reserved slots with the specified schedule 
repetition period (with the specified accuracy). The number of slots is the BS's estimate of the number of slots needed to 
send the specified quantity of data. 

NOTE: On a D8PSK or QAM channel, the BS's estimate will not always be correct because of the MS's link 
adaptation procedures. It is the MS's responsibility to request any additional slots needed. 

The scheduled access mechanism avoids the need for the MS to make frequent random access attempts in order to 
request reserved slot(s) for each TL-SDU. 
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The MAC is responsible for the schedule timing. On request from the SNDCP (via the MLE-CONFIGURE, 
TL-CONFIGURE and TMC-CONFIGURE request primitives), the MAC in the MS provides a schedule timing service 
to the higher layers, issuing schedule timing prompts (using the TMC-REPORT indication primitive) at intervals equal 
to the schedule repetition period. The synchronization of these prompts is initially based on the timing of the 
TMC-CONFIGURE request primitive. However, the BS may send the L2-SCHEDULE-S YNC message to define the 
schedule synchronization, in which case the MS-MAC bases the timing of further prompts on that synchronization. 

23.5.2.6.2 MS operation for sending scheduled messages 

When the SNDCP in the MS issues packet data to the lower layers, the "scheduled data status" parameter in the request 
primitive indicates whether the data should be treated as "not scheduled data", "initial scheduled data" or "scheduled 
data". When the SNDCP starts sending data using a context for which a schedule has been arranged, and after a 
substantial gap in the arrival of scheduled data from the service user, the SNDCP instructs the lower layers to treat the 
first TL-SDU as "initial scheduled data" (see clause 28); further TL-SDUs are then labelled as "scheduled data". 

In the DATA-IN-BUFFER signal, the LLC in the MS indicates whether the data in its sending buffer is "fully 
scheduled" or "unscheduled" or a mixture (see clause 223.1.9). For this purpose: 

• initial scheduled data is treated as "unscheduled" so that, for example, the MS-MAC may immediately use 
random access in order to send the data (if it does not have reserved capacity granted for this address on this 
control channel and has not already indicated a signalling requirement for this address on this control channel); 

• scheduled data is treated as "fully scheduled" (except for segment retransmissions), so that the MS-MAC 
generally waits for a slot grant instead of attempting random access; 

• all other types of data and signalling are treated as "unscheduled". 

The LLC also indicates the lowest value of the "maximum schedule interval" for all fully scheduled data in the buffer. 

NOTE 1 : The maximum schedule interval is the sum of the agreed schedule repetition period plus the schedule 
timing error. It therefore indicates the longest expected time between the granted slots for a particular 
schedule. 

The MS-MAC procedures for fully scheduled messages are similar to the procedures for unscheduled messages except 
that, if the DATA-IN-BUFFER signal indicates that all the data in the buffer is fully scheduled, the MS-MAC does not 
attempt random access unless it considers that the schedule agreement has not been honoured (see clauses 23.5. L4. 3 
and 23.5.2.4.2). 

Otherwise the procedures are similar to the procedures for unscheduled messages; therefore, for example: 

• When the MS-MAC transmits a MAC block containing a MAC-ACCESS, MAC-DATA, MAC-U-BLCK, 
MAC-END-HU or MAC-END PDU, the "reservation requirement" shall include the MS's estimate of the total 
capacity required for any further signalling messages that it has ready to send for this individual address on 
this control channel, including fully scheduled messages; see clause 23.5.2. L 

The "reservation requirement" therefore includes the capacity required for the remainder of the agreed quantity 
of data - including any additional slots needed because the MS may use a lower bit rate on a D8PSK or QAM 
channel than the BS's estimate assumed. It also covers additional slots needed, for example, if some scheduled 
SDUs are larger than the size agreed in the schedule, or if the MS has failed to receive slot grant(s) so that it 
has a backlog of scheduled messages to send, or if the MS also has unscheduled messages ready to send. 

• When the MS has been granted a slot or subslot for one of its individual addresses, the MS may use the slot or 
subslot for any signalling messages (basic link or advanced link, fully scheduled or unscheduled) to be sent for 
this address on this control channel; see clause 23.5.2.3. L 

When the MS is on a QAM channel, and may have a schedule or schedules in operation (e.g. if the MS has sent 
scheduled data recently), it should not send the Null PDU as the only PDU in an SCH-Q/HU or SCH-Q/F MAC block if 
it has already been granted further capacity for this address on this control channel (whether in one slot granting PDU, 
or more than one, and by either basic slot granting or multiple slot granting). 

NOTE 2: This is because the further capacity may be intended for the schedule(s), for data not yet issued by the 

SNDCP. If the MS sends the Null PDU as the only PDU in the SCH-Q/HU or SCH-Q/F MAC block, it is 
not permitted to use that further capacity; see clause 23.5.2.3. L 
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23.5.2.6.3 Schedule timing in MS 



The higher layers may issue a TMC -CONFIGURE request primitive containing the "schedule repetition information" 
parameter. The "schedule repetition information" parameter contains the following subparameters: 

• NSAPI; 

• start-stop flag (start or stop); 

• schedule repetition period (as a number of timeslot durations). 

If the MS-MAC receives a TMC-CONFIGURE request primitive containing the "schedule repetition information" 
parameter with the "start-stop" flag indicating "start" then it shall start to issue schedule timing prompts at intervals 
corresponding to the specified schedule repetition period. According to the protocol model, the schedule timing prompt 
is performed by issuing the TMC-REPORT indication primitive with the "Report" parameter set to "schedule timing 
prompt". The TMC-REPORT indication primitive shall indicate the NSAPI to which the schedule timing prompt 
applies. 

The MS-MAC shall continue issuing schedule timing prompts for that NSAPI at intervals corresponding to the 
specified schedule repetition period until: 

• it receives a TMC-CONFIGURE request primitive containing schedule repetition information for that NSAPI, 
with the "start-stop" flag indicating "start" and containing a different value of the schedule repetition period; or 

• it receives a TMC-CONFIGURE request primitive containing schedule repetition information for that NSAPI, 
with the "start-stop" flag indicating "stop". 

In the first case, the MS -MAC shall stop issuing schedule timing prompts at intervals corresponding to the old schedule 
repetition period and shall start issuing schedule timing prompts for that NSAPI at intervals corresponding to the new 
schedule repetition period. In the second case, the MS-MAC shall stop issuing schedule timing prompts for that NSAPI. 

The BS may send the L2-SCHEDULE-SYNC message to define the schedule synchronization. The 
L2-SCHEDULE-SYNC message contains the NSAPI to which the message applies and a "schedule synchronization 
point" expressed as a timeslot number, frame number and multiframe number. The MS-MAC shall regard the specified 
schedule synchronization point as being the uplink slot corresponding to the next occurring instance of that timeslot 
number, frame number and multiframe number. 

If the MS-MAC receives an L2-SCHEDULE-S YNC message while it is issuing schedule timing prompts for that 
NSAPI then: 

a) if appropriate, the MS-MAC shall continue to issue schedule timing prompts for that NSAPI using its current 
schedule synchronization until just before the schedule synchronization point specified in the 
L2-SCHEDULE-SYNC message; 

b) the MS-MAC shall then set its "schedule timing point" for that NSAPI to the schedule synchronization point 
specified in the L2-SCHEDULE-SYNC message; 

c) the MS-MAC shall then issue a schedule timing prompt for that NSAPI using a timing such that the following 
criteria 1 and 2 are both satisfied: 

1) scheduled data appropriate to this schedule timing prompt shall not be included in the "reservation 
requirement" or any "data priority blocks" in slots more than one slot before the uplink slot 
corresponding to the schedule timing point, if the MS transmits in those slots (see note 2); and 

2) the MS shall be capable of sending scheduled data appropriate to this schedule timing prompt in the 
uplink slot corresponding to the schedule timing point, if granted capacity is available at that time for 
that address on that control channel; 

d) the MS-MAC shall then increment the schedule timing point by the schedule repetition period for that NSAPI. 
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The MS-MAC shall then continue to perform actions c) and d) (i.e. issuing a schedule timing prompt for that NSAPI, 
using a timing such that criteria 1 and 2 are both satisfied for the schedule timing point, and then incrementing the 
schedule timing point by the current schedule repetition period for that NSAPI), until: 

• it receives a TMC-CONFIGURE request primitive from the higher layers instructing it to stop issuing 
schedule timing prompts for that NSAPI; or 

• it receives another L2-SCHEDULE-SYNC message for that NSAPI, in which case it shall obey the procedure 
above for the new schedule synchronization. 

NOTE 1 : The implementation methods in the MS for achieving the requirements in criteria 1 and 2 are outside the 
scope of the present document. For example, in an implementation, the MS could choose to hold the 
scheduled data appropriate to the schedule timing point in a separate buffer in the LLC until just before 
the schedule timing point instead of holding the scheduled data in the SNDCP. 

NOTE 2: In criterion 1, it is preferable that the MS does not include the scheduled data appropriate to this schedule 
timing prompt in the "reservation requirement" or "data priority blocks" in any slots before the uplink slot 
corresponding to the schedule timing point. However, for flexibility of implementation on a multi-slot 
channel, the MS is not precluded from including the scheduled data in the "reservation requirement" or 
any "data priority blocks" in the slot immediately preceding the uplink slot corresponding to the schedule 
timing point (if that slot is appropriate to this uplink control channel and the MS transmits in that slot). 

NOTE 3: After receiving an L2-SCHEDULE-SYNC message then, as specified above, the MS-MAC should base 
the timing of further prompts on that synchronization until it receives a TMC-CONFIGURE request 
primitive instructing it to stop issuing prompts or it receives another L2-SCHEDULE-S YNC message for 
that NSAPI. This continues to apply if the MS changes channel and even if it changes cell. 

NOTE 4: The procedures in this clause apply to a single address. If the MS has schedules on more than one address 
then the procedures in this clause apply independently for each address and the L2-SCHEDULE-SYNC 
message applies only to the schedule for the address on which the message was received. 

23.5.2.6.4 BS operation for granting slots for schedule 

The BS should start granting scheduled capacity to the MS when its SNDCP entity receives an SN-DATA or 
SN-UNITDATA PDU with NSAPI corresponding to an agreed schedule. The BS should then proceed to send slot 
grants appropriate to the schedule. 

The BS designer should choose criteria for when the BS stops sending slot grants appropriate to the schedule, for 
example, if the PDP context containing the schedule is deactivated, or if the SwMI suspends or cancels the schedule, or 
if the MS indicates that it is pausing use of the schedule or context, or if the BS repeatedly perceives that the slot grants 
are not used. In the last two cases, the BS should re-start the slot grants if its SNDCP entity receives an SN-DATA or 
SN-UNITDATA PDU with NSAPI corresponding to an agreed schedule. 

When the schedule is negotiated at the SNDCP level, the agreement is that the BS will grant a number of slots with the 
specified schedule repetition period (and with the specified accuracy). The number of slots is the BS's estimate of the 
number of slots needed to send the specified quantity of data. On a D8PSK or QAM channel, the BS does not know 
which bit rate the MS will use to send the data. Therefore the BS should estimate the bit rate that the MS will use and 
then estimate the number of slots for that bit rate. (When the MS uses the slot(s), it will include any reservation 
requirement for the remainder of the scheduled data and for any other data.) 

The "granting delay" element allows a basic slot grant to be delayed by up to 13 delay opportunities. 

• On a 71/4-DQPSK or D8PSK channel, the BS should not attempt to use the granting delay facility to grant 
multiple disjoint resources in advance to an MS with a schedule whose period corresponds to less than 

13 delay opportunities. This is because, when the MS sends any SCH/HU or SCH-P8/HU MAC block that 
does not include a "reservation requirement" element or any SCH/F or SCH-P8/F MAC block that contains a 
MAC -DATA or MAC -END PDU and does not include a "reservation requirement" element or a 
MAC-U-BLCK PDU indicating no reservation requirement, the MS is not permitted to use any other capacity 
that has already been granted for this address on this control channel. If the MS used one of the disjoint 
resources for a scheduled message, it would usually have no further reservation requirement at that time and 
therefore would not be able to use the other disjoint resources. 
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• The BS may use multiple slot granting on a QAM channel. As described in clause 23.5.2.2.3, this allows the 
BS to grant disjoint resources with one slot grant by including multiple explicit instances of the "basic slot 
granting" element and/or by using an implicit repeat mechanism for each instance of the "basic slot granting" 
element. Multiple slot granting may be useful for allocating resources to an MS using scheduled access with a 
fairly short schedule repetition period (i.e. within the range of the "granting delay" element), or for allocating 
resources to other MSs sharing the channel with an MS that is using scheduled access; see clause 23.5.2.2.7. 

23.5.2.6.5 Schedule synchronization by BS 

The BS may send the L2-SCHEDULE-SYNC message to an MS in order to synchronize the times at which the SNDCP 
in the MS issues the scheduled data to the lower layers with the earliest times that the BS intends for the scheduled 
reserved slots. 

NOTE 1: If the BS does not use the L2-SCHEDULE-SYNC message then, for some schedule repetition periods, if 
the MS also has other data to send while the schedule is running, there are cases when the MS may send 
its scheduled data with the other data before the reserved slots intended for the scheduled data. If this 
occurs, the MS may then have no data to send in the reserved slots intended for the scheduled data. 

NOTE 2: If the BS uses the L2-SCHEDULE-SYNC message, the BS designer should note that, for flexibility of 
MS implementation on a multi-slot channel, the MS may include the scheduled data in the "reservation 
requirement" (and any "data priority blocks") if it transmits in the slot immediately preceding the uplink 
slot corresponding to the schedule timing point; see clause 23.5.2.6.3. 

The BS may send a slot grant with the L2-SCHEDULE-SYNC message, in order to obtain an implicit 
acknowledgement that the message was received by the MS. 

The BS includes a timeslot number, frame number and multiframe number in the L2-SCHEDULE-SYNC message, 
defining a schedule synchronization point for that NSAPI in the addressed MS. This refers to the next occurring 
instance of the uplink slot corresponding to that timeslot number, frame number and multiframe number. The BS should 
send the L2-SCHEDULE-SYNC message at least two TDMA frames before the time corresponding to the intended 
schedule synchronization point in order to allow for processing delays in the MS (thereby avoiding a possible difference 
of perception about which hyperframe is intended). 

The BS may update the schedule synchronization information for an NSAPI at any time by sending a further 
L2-SCHEDULE-SYNC message for that NSAPI to the same MS address. 

It should be noted that the MS may discard the information received in an L2-SCHEDULE-SYNC message when: 

• the PDP context containing the schedule is deactivated; or 

• the SwMI suspends or cancels the schedule; or 

• the SNDCP in the MS goes into the STANDBY state (see clause 28). 

Therefore, in these cases, the BS should send a new L2-SCHEDULE-SYNC message if use of the schedule re-starts and 
the BS wishes to synchronize the schedule. 

23.5.3 Cancel request 

The LLC may use the TMA-CANCEL request primitive to stop the MAC activities relating to a particular 
TMA-UNITDATA request primitive. The "handle to the request" references the service request that is to be aborted. 

On reception of a TMA-CANCEL request primitive from the LLC, the MS-MAC shall cease all activities related to the 
service request as identified by its handle. The MS -MAC shall report to the LLC that MAC transmission activities have 
been aborted, indicating whether: 

a) the TM-SDU has not been completely sent; or 

b) the complete TM-SDU has been sent at least once, 
using the TMA-REPORT indication primitive. 
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NOTE 1 : This procedure can be used by the LLC to abort transmission of a message until: 

■ the complete TM-SDU, or final fragment of a fragmented TM-SDU, has been sent by reserved 
access or by stealing; or 

■ the complete TM-SDU has been sent and acknowledged by random access. 

After a first transmission of a random access message, the TMA-CANCEL request primitive stops the 
MS-MAC from sending further random access retries. However, it should be noted that the BS may have 
received the message. 

NOTE 2: The primitive TMA-CANCEL request is used for modelling purposes only. 

23.5.4 Channel allocation 

23.5.4.1 Transmission of channel allocation 

The BS may send a channel allocation command either: 

a) to instruct an addressed MS (or MSs) to move from the current channel to another channel; or 

b) to allocate an additional channel for the addressed MS (or MSs). If the MS does not support concurrent MAC 
services (i.e. if it is not capable of operating on multiple channels) then it may either remain on the current 
channel and reject the new service or move from the current channel to the new channel and accept the new 
service. 

The BS shall perform the allocation by including the "channel allocation" element in a MAC -RESOURCE or 
MAC-END PDU. The "channel allocation" element is an optional element, included only when required. 

The channel allocation is generally sent in a MAC -RESOURCE PDU. However, if the BS wishes to send channel 
allocation information with a fragmented message then that information shall be included within the MAC-END PDU 
and shall not be included within the MAC-RESOURCE PDU. 

For the MAC -RESOURCE PDU, the channel allocation shall refer to the MS or MSs addressed in the MAC header. For 
the MAC-END PDU, the channel allocation shall refer to the MS or MSs receiving the fragmented message (addressed 
in the MAC-RESOURCE PDU that contained the first fragment). 

The channel allocation command may be used to allocate a different channel (timeslot or timeslots) on the current RF 
carrier or to change both the carrier and timeslot(s) (see clause 21). 

When the BS directs the MS to an assigned channel, it shall set element "timeslot assigned" to indicate the appropriate 
timeslot(s), as a bit map. If the BS wishes the MS to return to a common control channel (i.e. MCCH or common 
SCCH), it shall set "timeslot assigned" = OOOO2 and indicate the main carrier number. 

The channel allocation command is used to allocate a 7i/4-DQPSK channel. Alternatively, the channel allocation 
command may indicate that the allocated channel is a D8PSK channel or a QAM channel. In the case of a QAM 
channel, the BS indicates whether the bandwidth of the allocated channel is 25 kHz, 50 kHz, 100 kHz or 150 kHz. 

The channel allocation command may be used to allocate a channel on the current cell. It may also be used to allocate a 
channel on another cell e.g. in case of announced cell reselection type 1. The "cell change flag" shall indicate whether 
the channel allocation is for another cell. For a channel allocation directing an MS to another cell, the bit map in 
element "timeslot assigned" shall refer to the timeslot numbering on the new cell. 

NOTE 1: The channel allocation method is used for directing addressed MSs to a specified channel. In addition, the 
broadcast message SYSINFO PDU (the content of BNCH) may cause an MS to move from one common 
control channel to another, e.g. when the number of common SCCHs is changed (see clause 23.3). For 
such a move, the same endpoint identifier applies, and the same service to the LLC is maintained for 
basic link and for any advanced link(s). 

NOTE 2: When the BS assigns a channel for a circuit mode call, the resource allocation should correspond to that 
required for the network layer basic service information for the call (see clause 14). For example, the 
number of slots per TDMA frame allocated by element "timeslot assigned" should match the basic service 
information. 
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NOTE 3: It is optional for the MS to be capable of using a multi-slot channel, or of supporting concurrent channels 
on one carrier, or of supporting concurrent multi-carrier operation, or of supporting D8PSK channels, or 
of supporting QAM channels, or of supporting bandwidths greater than 25 kHz. The BS should use the 
information on MS capabilities provided in the "class of MS" and "extended capabilities" elements (see 
clause 16) when allocating resources. 

NOTE 4: In many cases, the MS may choose whether to move to an allocated channel (see clause 23.5.4.2). This 
applies for both individually addressed and group addressed channel allocations. BS designers should 
take account of this in their BS algorithms. 

23.5.4.2 Reception of channel allocation 
23.5.4.2.1 Channel allocation types 

The channel allocation element includes a two-bit element "allocation type", which is intended to aid interpretation of 
the allocation. The precise procedures are defined in clauses 23.5.4.2.2, 23.5.4.2.3 and 23.5.4.2.4. 

The values for the "allocation type" are as follows: 

a) OO2: Replace current channel with specified channel. 

This indicates that the allocated channel is intended to replace the current channel (i.e. the channel on which 
the command was received). This replacement applies only to the channel on which the command was 
received, not to any other concurrent channels that the MS may be using on that carrier. If the current channel 
is a multi-slot channel, the replacement applies to all the timeslots comprising that channel. 

The "Replace" mechanism may be used to move the MS to a different resource allocation. Otherwise it may be 
used if the BS wishes to increase or decrease the number of slots allocated to a particular assigned channel; the 
BS sends a "Replace" channel allocation on the assigned channel indicating the revised slot allocation. 

b) 01 2: Additional channel allocation. 

This indicates the allocation of an additional independent channel for an independent service e.g. a concurrent 
service. It cannot be used for changing the configuration of the current channel (see above). 

c) IO2: Quit current channel and go to specified channel. 

This allows the BS to replace the current channel but without maintaining full service. This means that the 
physical layer service is no longer available for the higher layers to use, though the higher layer service is not 
necessarily disconnected. Any current traffic transmit/receive authorization does not apply on the new channel 
(see clause 23.8.2). 

d) 11 2: Replace current channel with specified channel, plus MCCH/SCCH or additional carrier specific 
signalling channel (CSS channel) in timeslot 1. 

This indicates that the specified channel is intended to replace the current channel (i.e. the channel on which 
the command was received). If the specified carrier is the main carrier, it indicates that the MS may, if capable, 
use also the MCCH or the appropriate common SCCH for that MS. If the specified carrier is not the main 
carrier, it indicates that the MS may, if capable, use timeslot 1 as an additional channel (referred to as a CSS 
channel) to increase signalling capacity between the MS and BS. If the MS is not capable of receiving both the 
specified channel and the MCCH/SCCH or CSS channel then the specified channel shall take precedence. 

If the specified carrier is the main carrier and the MS chooses to use the MCCH or the appropriate common 
SCCH then it shall regard that channel as a common control channel (in the usual way), within the capabilities 
of that MS. 
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If the specified carrier is not the main carrier and the MS chooses to use the CSS channel then it shall regard 
that CSS channel as an independent single-slot 7i/4-DQPSK channel. For the purposes of the general 
procedures for transmission and reception of signalling messages, the MS shall apply those procedures as if 
the CSS channel were a 7i/4-DQPSK assigned channel, allocated by a specific MAC-RESOURCE or 
MAC -END PDU with "timeslot assigned" = IOOO2, i.e. allocation of timeslot 1. However, the MS is only 
required to receive the CSS channel within the capabilities of that MS. Also, reduced channel maintenance 
procedures shall apply on the CSS channel, and the CSS channel becomes invalid when the MS has no other 
assigned channel on that carrier (see clause 23.5.6.2). 

EXAMPLE: The BS might decide to allocate a CSS channel to provide information to MSs on that carrier 

about new calls, e.g. late entry signalling, without disturbing the operation of the assigned SCCHs 
and traffic channels on the other timeslots. The CSS channel could also be used for other 
signalling purposes such as status messages or packet data. 

NOTE 1: The BS may allocate the CSS channel to all MSs using that carrier, by setting the "allocation type" to 1 12 
in all the channel allocations. Slot 1 could also be an assigned channel for some MSs e.g. for advanced 
links with low data transfer throughput. The channel is then shared between the MSs. 

An MS in a circuit mode call may, for example, send the U-TX DEMAND PDU on the CSS channel, 
e.g. with a high priority request. However, if FACCH is available on the assigned channel, then the MS 
should use this in preference to the CSS channel. 

NOTE 2: The MS only receives the common channel (i.e. MCCH or common SCCH) or CSS channel within the 
capabilities of that MS. For example, a frequency half duplex MS in a simplex circuit mode call is 
permitted to receive the common or CSS channel while it is receiving traffic on the assigned channel even 
if it is not capable of receiving the common or CSS channel while it is transmitting traffic. 

NOTE 3: Use of "allocation type" 1 12 is not appropriate when the BS is allocating a QAM channel. 

Use of "allocation type" 1 12 is vaHd when the BS is allocating a 7i/4-DQPSK or D8PSK channel; in both 
cases, the CSS channel is a 7i/4-DQPSK channel. 

In many cases, the MS may choose whether to obey a channel allocation e.g. if the channel allocation is received on the 
MCCH or on a common SCCH, or for an additional channel allocation. The MS-MAC refers to the higher layers for a 
decision. For a group addressed channel allocation, the higher layers may either make an immediate decision on 
whether to accept the channel allocation or may delay the decision. However, for an individually addressed channel 
allocation, the MS needs to make an immediate decision on whether to accept a particular channel allocation. 

NOTE 4: For a group call, especially on a (quasi-)transmission trunked system, the MS may sometimes receive a 
channel allocation on the group address and sometimes on its individual address. 

When the higher layers respond with their decision on whether to accept a channel allocation, they may indicate 
"accept" or "reject" or, in some cases, they may indicate "ignore". The MAC actions for "reject" and "ignore" are the 
same except when a "replace" or "replace + CSS channel" or "quit" channel allocation is received on an assigned 
channel or when a "quit" channel allocation is received on a CSS channel (see clauses 23.5.4.2.3 and 23.5.4.2.4). 

The "reject" instruction is used when the higher layers may choose not to accept the channel allocation. The "ignore" 
instruction applies only in specific protocol cases when the higher layers are required by the protocol to ignore specific 
PDUs and to instruct the MAC to ignore any channel allocation received with those PDUs e.g. when the MS is 
transmitting traffic and the CMCE receives a group addressed D-TX GRANTED or D-TX INTERRUPT PDU, or in 
some instances of receipt of a group addressed D-SETUP PDU when the MS is trying to make a call to that group (see 
clause 14.5.2), or if the SNDCP receives a group addressed SN-END OF DATA PDU while the READY timer is active 
(see clause 28.2.4.7). 

The following procedures for reception of a channel allocation indicate the physical layer service provided by the 
channel to the higher layers. 

The MS-MAC generally uses the TMC-CONFIGURE indication primitive to inform the higher layers when it has lost 
physical resources. There are also some error conditions (as defined in clause 23.5.4.2.3 procedure al, or if the MS 
leaves the channel as a result of channel maintenance procedures) for which the MS-MAC may either issue a 
TMC-CONFIGURE indication primitive indicating loss of the physical resource or alternatively may issue the 
TMA-RELEASE indication primitive to indicate loss of the connection. 
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NOTE 5: When the LLC receives a TMC-CONFIGURE indication primitive indicating loss of the physical 

resource, it may retain any advanced links on that resource for potential continuation (see clause 22.3.5). 
When the LLC receives the TMA-RELEASE indication primitive, it locally disconnects any advanced 
links on that resource (see clause 22.3.3.4). 

23.5.4.2.2 Reception of channel allocation on MCCH or common SCCH 

If the MS receives a channel allocation on the MCCH or on a common SCCH for one of its valid addresses or for a 
corresponding event label, then the "allocation type" may be OO2 (Replace current channel) or 01 2 (Additional channel) 
or 11 2 (Replace current channel, and add CSS channel). 

If a TM-SDU was included within the PDU that allocated the channel then the MS-MAC shall set the "channel change 
response required" parameter to "true" in the TMA-UNITDATA indication primitive, to indicate that a response is 
required to instruct the MS-MAC whether it should obey the allocation; the MS-MAC may also include information 
about the channel allocation, using the "channel information" parameter. The MS-MAC shall generate a local identifier 
for the channel allocation, referred to as the "channel change handle", and shall include it in the TMA-UNITDATA 
indication primitive, enabling unique identification of the related response from the higher layers. If a TM-SDU was not 
included within the PDU that allocated the channel then the MS-MAC shall issue a TMA-UNITDATA indication 
primitive containing the "channel change response required" parameter set to "true" (and a channel change handle and, 
optionally, the channel information parameter) and with no TM-SDU. 

NOTE 1 : It is optional for the MS to obey a channel allocation received on the MCCH or on a common SCCH. 
According to the protocol model, the MS-MAC refers to the higher layers so that, for example, for a 
circuit mode group call, the MS-MAC does not move to the channel if the CMCE does not accept the 
associated message. However, in an implementation, the MS is permitted to obey all individually 
addressed channel allocations in which case the primitive exchange is unnecessary in practice. 

When the BS sends a channel allocation on the MCCH or on a common SCCH, it is recommended that 
the BS includes a higher layer message indicating the intended usage of the channel allocation. Even if 
only an LLC acknowledgement is included with the channel allocation, this may enable the MS to deduce 
the intended usage (e.g. in the case of medium channel assignment to a called MS). 

If "allocation type" = OI2 and the MS is capable of operating with concurrent channels and the MS is not already 
receiving the indicated channel then the MS -MAC shall allocate an endpoint identifier for the new channel. The 
MS-MAC shall include both the endpoint identifier of the current channel (i.e. the channel on which the channel 
allocation PDU was received) and the endpoint identifier of the newly allocated channel (parameter "new endpoint 
identifier") in the TMA-UNITDATA indication primitive. 

NOTE 2: A new endpoint identifier will usually be required. However, for example, in the case of independent 
allocation of uplink and downlink for concurrent calls involving the same MS, that MS may receive 
independent channel allocations with the same carrier number and same element "timeslot assigned" but 
with a different up/downlink assigned designation. 

NOTE 3: The new endpoint identifier enables the higher layers to make the intended usage of the new channel if 
the MS-MAC obeys the channel allocation. For example, for an AL-SETUP PDU for a new advanced 
link, sent with the additional channel allocation, the new advanced link is intended to be on the allocated 
channel. 

If "allocation type" = II2 and the MS is capable of using the common or CSS channel then the MS-MAC shall allocate 
an endpoint identifier for the common or CSS channel. The MS-MAC shall include both the endpoint identifier of the 
current channel and the endpoint identifier of the common or CSS channel (parameter "CSS endpoint identifier") in the 
TMA-UNITDATA indication primitive. 

NOTE 4: The CSS endpoint identifier enables the higher layers to make correct usage of the common or CSS 
channel if the MS-MAC obeys the channel allocation. 

The MS-MAC should then receive a response (TMC-CONFIGURE request primitive) from the higher layers indicating 
whether it should obey the allocation. For an individually addressed channel allocation, the MS-MAC should expect 
that the response from the higher layers will be immediate. However, for a group addressed channel allocation, the 
response from the higher layers may be immediate or may be delayed, in which case the MS-MAC continues to obey 
the normal MAC procedures on the MCCH or common SCCH in the interim time. 
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NOTE 5: For the purposes of the protocol description, it is assumed that, in the case of an immediate decision by 
the higher layers, the process of the MAC issuing the TMA-UNITDATA indication primitive and then 
receiving the corresponding TMC-CONFIGURE request primitive is effectively instantaneous. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" parameter 
set to "reject" or "ignore" then the MS-MAC shall ignore the channel allocation corresponding to the channel change 
handle. The MS may use any subslot or slot(s) that are granted on the current channel but shall ignore a slot grant if 
element "position of grant" in the channel allocation PDU indicated the allocated channel. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" parameter 
set to "accept" then the MS-MAC shall obey the channel allocation command corresponding to the channel change 
handle, using the appropriate procedure a) or b): 

a) If "allocation type" = OO2 (Replace) or 1 12 (Replace + CSS channel) in the channel allocation element then the 
MS shall move from the current channel (i.e. the channel on which the channel allocation PDU was received) 
to the specified channel. It shall assume that the allocated channel will provide the same service to the LLC as 
the current channel, corresponding to the same endpoint identifier (see note 6). 

If the MS was receiving other channels on the main carrier, and it is not capable of receiving those other 
channels as well as the newly allocated channel, then the MS-MAC shall issue a TMC-CONFIGURE 
indication primitive to the higher layers for any channels that it can no longer receive in order to indicate that 
the physical resource on those channels is lost. Otherwise, if the MS is capable of continuing to receive its 
other channels, then those other channels are not affected. 

If "allocation type" = OO2 then the MS shall not continue to use the MCCH or common SCCH. 

If "allocation type" = 1 12 and the assigned carrier is the main carrier then the MS may, if capable, use also the 
MCCH or the appropriate common SCCH for that MS. If the assigned carrier is not the main carrier then the 
MS may, if capable, use slot 1 of the assigned carrier as a CSS channel. If the MS is not capable of receiving 
both the assigned channel and the common or CSS channel then the MS shall ignore the common/CSS part of 
the allocation. 

NOTE 6: For a "replace" or "replace + CSS channel" command within the cell, the service provided to the LLC is 
maintained both for the basic link and for any advanced link(s) on the current channel. This applies even 
if the number of allocated timeslots or modulation mode or bandwidth changes. (Though, for 7i/4-DQPSK 
operation, in the case of a change of the number of allocated timeslots, the MS is not precluded from 
performing an LLC reset if the AL-SETUP PDU contained radio resource information; also, in the case of 
a change of modulation mode or bandwidth, the MS is not precluded from performing an LLC reset in 
order to avoid use of fragmentation for re-transmissions of segments cut for transmission on the old 
channel.) In the case of a cell reselection, the MLE decides whether to release current advanced links or 
attempt reconnection. If the MLE does not attempt reconnection then any current advanced links are 
released when the MS obeys a channel allocation indicating a cell change. 

NOTE 7: A "replace" or "replace + CSS channel" command applies only to the channel on which the message was 
received, and so cannot be used to simultaneously replace other concurrent channels on that carrier when 
allocating a channel on another carrier. However, if the channel allocation PDU includes a slot grant on 
the current channel with "granting delay" > OOOO2 then the MS does not change channel immediately (see 
clause 23.5.4.3.1). During the interim time, the MS should continue to receive its other concurrent 
channels, since the BS may also send a "replace" or "replace + CSS channel" command on one of those 
channels, enabling both services to be maintained on the new carrier. Then, in the timing procedure for 
the carrier change, the MS may use the later (or latest) of the specified times. 

b) If "allocation type" = OI2 (Add) in the channel allocation element then the MS shall obey the command to 
receive the allocated channel. 

If the MS is not capable of receiving all concurrent channels as well as the newly allocated channel, then the 
MS-MAC shall issue a TMC-CONFIGURE indication primitive to the higher layers for those channels that it 
can no longer receive in order to indicate that the physical resource on those channels is lost. Otherwise the 
MS shall continue to receive all concurrent channels, including the channel on which the channel allocation 
PDU was received, as well as the newly allocated channel. 

After a channel change, the MS-MAC shall inform the MLE about the channel now in use using the TMC-SELECT 
indication primitive. 
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23.5.4.2.3 Reception of channel allocation on assigned channel 

If the MS receives a channel allocation on an assigned channel for one of its valid addresses or for a corresponding 
event label, then the "allocation type" may take any of the following four values: 

• OO2 (Replace current channel), in which case the MS shall assume that the allocated channel will provide the 
current service. 



• 



OI2 (Additional channel), in which case the MS shall assume that the channel is intended for the purpose 
indicated in the higher layer message. 

• IO2 (Quit current channel), in which case the MS should assume that the current service on that channel is not 
fully maintained. This means that the physical layer service is no longer available for the higher layers to use, 
though the higher layer service is not necessarily disconnected. Any current traffic transmit/receive 
authorization does not apply on the new channel. 

• II2 (Replace current channel, and add CSS channel), in which case the MS shall assume that the allocated 
channel will provide the current service, and that timeslot 1 (or the MCCH or common SCCH) may be used 
for additional signalling. 

NOTE 1: For a "replace" or "replace + CSS channel" command received while the MS is in a circuit mode call, 
current traffic transmit and/or receive authorization may apply on the allocated channel; refer to 
clause 23.8.2. 

The MS-MAC shall follow the appropriate procedure a), b) or c): 

a) For allocation type OO2 (Replace) or 11 2 (Replace + CSS channel), the appropriate procedure shall apply as 
follows: 

1) If a TM-SDU was not included within the PDU that allocated the channel, and: 

■ the MS does not have a concurrent assigned channel; or 

■ the MS would still be able to receive any concurrent assigned channels after moving to the 
allocated channel, 

then the MS-MAC shall decide whether to obey the channel allocation as follows: 

■ If the MS is capable of using the allocated channel then the MS-MAC shall obey the channel 
allocation. The MS shall cease to receive the current channel (unless it has a concurrent 
independent allocation on that channel, see note 6) and shall move to the allocated channel. 

■ Otherwise, if the MS is not capable of using the allocated channel (e.g. the replacement channel has 
a larger number of slots than the current channel and the MS cannot support the channel, or the MS 
cannot support the indicated modulation mode or bandwidth) then the MS-MAC shall reject the 
channel allocation. The MS-MAC shall cease to receive the current channel and shall issue either a 
TMA-RELEASE indication primitive to indicate loss of the connection or a TMC -CONFIGURE 
indication primitive indicating loss of the physical resource (unless it has a concurrent independent 
allocation on that channel, see note 6). The MS may use any subslot or slot(s) that are granted on 
the current channel but shall ignore a slot grant if element "position of grant" in the channel 
allocation PDU indicated the allocated channel. If the MS does not have a concurrent assigned 
channel, it shall return to the MCCH or appropriate common SCCH. 

NOTE 2: For allocation type 11 2: when the above procedure refers to the MS not being capable of using the 

allocated channel, this refers only to the allocated channel as indicated by element "timeslot assigned", 
not to the CSS channel. 
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2) If a TM-SDU was included within the PDU that allocated the channel, or the MS has a concurrent 

assigned channel that it would be unable to receive as a result of moving to the allocated channel, then 
the MS -MAC shall set the "channel change response required" parameter in the TMA-UNITDATA 
indication primitive to "true" (and shall include a channel change handle and may include the channel 
information parameter). The MS-MAC shall then wait for a response from the higher layers: 

■ If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change 
accepted" parameter set to "accept" then the MS -MAC shall obey the channel allocation 
corresponding to the channel change handle. The MS shall cease to receive the current channel 
(unless it has a concurrent independent allocation on that channel, see note 6) and shall move to the 
allocated channel. 

■ If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change 
accepted" parameter set to "reject" then the MS shall cease to receive the current channel (unless it 
has a concurrent independent allocation on that channel, see note 6). The MS may use any subslot 
or slot(s) that are granted on the current channel but shall ignore a slot grant if element "position of 
grant" in the channel allocation PDU indicated the allocated channel. If the MS does not have a 
concurrent assigned channel, it shall return to the MCCH or appropriate common SCCH. 

■ If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change 
accepted" parameter set to "ignore" then the MS-MAC shall ignore the channel allocation 
corresponding to the channel change handle and continue to use the current channel. The MS may 
use any subslot or slot(s) that are granted on the current channel but shall ignore a slot grant if 
element "position of grant" in the channel allocation PDU indicated the allocated channel. 

■ If the higher layers do not return a TMC-CONFIGURE request primitive containing the "channel 
change accepted" parameter within a time T.216 following receipt of the channel allocation then 
the MS shall cease to receive the current channel (unless it has a concurrent independent allocation 
on that channel, see note 6). If the MS does not have a concurrent assigned channel, it shall return 
to the MCCH or appropriate common SCCH. If the higher layers later return a TMC-CONFIGURE 
request primitive containing the "channel change accepted" parameter set to "accept" then the MS 
should move to the allocated channel. 

NOTE 3: Thus, when the higher layers wish the MS-MAC to ignore a replacement channel allocation on an 
assigned channel, they return the "channel change accepted" parameter set to "ignore" within a time 
T.216 in order for the MS-MAC to act on it. 

NOTE 4: In the case of a channel allocation with a slot grant on the current channel, when the above procedures 1) 
and 2) refer to the MS ceasing to receive the current channel, the MS should not leave the channel until 
after the end of the last uplink slot granted by that PDU (or the end of the slot containing a granted 
subslot). Similarly, if the current channel is a multi-slot channel, and the next immediate uplink slot 
following the channel allocation is part of the current channel, and the MS is transmitting traffic in that 
slot or was previously granted that slot (or a subslot in that slot) for reserved access, the MS should not 
leave until after the end of that next immediate uplink slot. 

b) For allocation type OI2 (Add), the MS-MAC shall set the "channel change response required" parameter in the 
TMA-UNITDATA indication primitive to "true" to indicate that a response is required to instruct the MAC 
whether it should accept the allocation (and shall include a channel change handle and may include the 
channel information parameter). If the decision is delayed for a group addressed channel allocation then the 
MS-MAC may continue to use the current channel in the interim time. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" 
parameter set to "accept" then the MS -MAC shall obey the channel allocation command corresponding to the 
channel change handle. It may also continue to use the current channel if it is capable of doing so. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" 
parameter set to "reject" or "ignore" then the MS-MAC shall ignore the channel allocation corresponding to 
the channel change handle and continue to use the current channel. The MS may use any subslot or slot(s) that 
are granted on the current channel but shall ignore a slot grant if element "position of grant" in the channel 
allocation PDU indicated the allocated channel. 
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c) For allocation type IO2 (Quit), the MS-MAC shall obey the procedure defined in procedure a) above for 

allocation type OO2 (Replace) except that, if the MS ceases to receive the current channel, the MS -MAC shall 
issue a TMC-CONFIGURE indication primitive for the current channel in order to indicate that the physical 
resource has been lost. 

If the MS is already receiving the allocated channel then any services on that channel are unaffected and the 
endpoint identifier is unchanged. 

After obeying a channel allocation command then, if the MS is not capable of receiving all concurrent channels as well 
as the newly allocated channel, the MS -MAC shall issue a TMC-CONFIGURE indication primitive to the higher layers 
for those channels that it can no longer receive in order to indicate that the physical resource on those channels is lost. 

After a channel change, the MS-MAC shall inform the MLE about the channel now in use using the TMC-SELECT 
indication primitive. 

NOTE 5: For allocation type OI2 (Add) or 1 12 (Replace + CSS channel), the MS-MAC may need to allocate 
additional endpoint identifiers, in a similar manner to that described in clause 23.5.4.2.2. 

NOTE 6: As indicated in clause 23.3.4, it is possible that an MS may receive concurrent independent channel 

allocations for the uplink and downlink of the same channel. If the BS has sent channel allocations that 
have assigned the uplink and downlink independently to the same MS (e.g. both on the MS's individual 
address, or one on the MS's individual address and the other on one of the MS's valid group addresses) 
then the BS should include a higher layer message when it sends a "replace" or "replace + CSS channel" 
command on that channel, thus enabling the MS to deduce which channel allocation is being replaced. 
This applies also for a "quit" command. 

NOTE 7: When the BS sends an additional channel allocation (allocation type OI2) on an assigned channel, it 
should include a higher layer message indicating the intended usage of the channel allocation; even if 
only an LLC acknowledgement is included with the channel allocation, this may enable the MS to deduce 
the intended usage. 

23.5.4.2.4 Reception of channel allocation on CSS channel 

If the MS receives a channel allocation on a CSS channel for one of its valid addresses or for a corresponding event 
label, then the "allocation type" may take any of the four values. 

a) For allocation type OO2 (Replace) or 1 12 (Replace + CSS channel), the MS-MAC shall set the "channel change 
response required" parameter in the TMA-UNITDATA indication primitive to "true" (and shall include a 
channel change handle and may include the channel information parameter). If the decision is delayed for a 
group addressed channel allocation then the MS-MAC may continue to use the CSS channel in the interim 

time. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" 
parameter set to "reject" or "ignore" then the MS-MAC shall ignore the channel allocation and may continue to 
use the CSS channel. The MS may use any subslot or slot(s) that are granted on the CSS channel but shall 
ignore a slot grant if element "position of grant" in the channel allocation PDU indicated the allocated channel. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" 
parameter set to "accept" then the MS-MAC shall obey the channel allocation command. If "allocation 
type" = 1 12 in a channel allocation indicating the current carrier then the MS may continue to use the CSS 
channel. However, if either: 

1) "allocation type" = OO2; or 

2) "allocation type" = 1 12 in a channel allocation directing the MS to another carrier; 

then the MS shall not continue to use the CSS channel on the current carrier though, in case 2), it may use the 
common or CSS channel on the new carrier. 
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b) For allocation type OI2 (Add), the MS-MAC shall set the "channel change response required" parameter in the 
TMA-UNITDATA indication primitive to "true" (and shall include a channel change handle and may include 
the channel information parameter). If the decision is delayed for a group addressed channel allocation then 
the MS-MAC may continue to use the CSS channel in the interim time. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" 
parameter set to "reject" or "ignore" then the MS-MAC shall ignore the channel allocation and may continue to 
use the CSS channel. The MS may use any subslot or slot(s) that are granted on the CSS channel but shall 
ignore a slot grant if element "position of grant" in the channel allocation PDU indicated the allocated channel. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change accepted" 
parameter set to "accept" then the MS -MAC shall obey the channel allocation command. It may also continue 
to use the CSS channel if it is capable of doing so. 

c) For allocation type IO2 (Quit), the appropriate procedure shall apply as follows: 

1) If a TM-SDU was not included within the PDU that allocated the channel and the MS would still be able 
to receive its current assigned channel(s) after moving to the allocated channel and the MS is capable of 
using the allocated channel then the MS-MAC shall obey the channel allocation. It shall cease to receive 
the CSS channel using the timing for an immediate decision and shall move to the allocated channel. 

2) If a TM-SDU was not included within the PDU that allocated the channel, and either the MS would be 
unable to receive its current assigned channel(s) after moving to the allocated channel (e.g. if the channel 
allocation is directing the MS to the common control channel and the MS is not capable of concurrent 
multi-carrier operation) or the MS is not capable of using the allocated channel, then the MS-MAC shall 
cease to receive the CSS channel using the timing for an immediate decision but shall not move to the 
allocated channel. 

3) If a TM-SDU was included within the PDU that allocated the channel then the MS-MAC shall set the 
"channel change response required" parameter in the TMA-UNITDATA indication primitive to "true" 
(and shall include a channel change handle and may include the channel information parameter). The 
MS-MAC shall then wait for a response from the higher layers: 

■ If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change 
accepted" parameter set to "accept" then the MS -MAC shall obey the channel allocation. The MS 
shall cease to receive the CSS channel and shall move to the allocated channel. 

■ If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change 
accepted" parameter set to "reject" then the MS shall cease to receive the CSS channel. The MS 
may use any subslot or slot(s) that are granted on the CSS channel but shall ignore a slot grant if 
element "position of grant" in the channel allocation PDU indicated the allocated channel. 

■ If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change 
accepted" parameter set to "ignore" then the MS-MAC shall ignore the channel allocation and may 
continue to use the CSS channel. The MS may use any subslot or slot(s) that are granted on the 
CSS channel but shall ignore a slot grant if element "position of grant" in the channel allocation 
PDU indicated the allocated channel. 

■ If the higher layers do not return a TMC-CONFIGURE request primitive containing the "channel 
change accepted" parameter within a time T.216 following receipt of the channel allocation then 
the MS shall cease to receive the CSS channel. If the higher layers later return a 
TMC-CONFIGURE request primitive containing the "channel change accepted" parameter set to 
"accept" then the MS should start to receive the allocated channel. 

If the MS ceases to receive the CSS channel, the MS-MAC shall issue a TMC-CONFIGURE indication 
primitive for the CSS channel in order to indicate that the physical resource has been lost. 

If the MS is already receiving the allocated channel then any services on that channel are unaffected and the 
endpoint identifier is unchanged. 

NOTE 1: In the case of a channel allocation with a slot grant on the CSS channel, when the above procedures refer 
to the MS ceasing to receive the CSS channel, the MS should not leave the channel until after the end of 
the last uplink slot granted by that PDU (or the end of the slot containing a granted subslot). 
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After obeying a channel allocation command then, if the MS is not capable of receiving all concurrent channels as well 
as the newly allocated channel, the MS -MAC shall issue a TMC-CONFIGURE indication primitive to the higher layers 
for those channels that it can no longer receive in order to indicate that the physical resource on those channels is lost. 

After a channel change, the MS-MAC shall inform the MLE about the channel now in use using the TMC-SELECT 
indication primitive. 

NOTE 2: For allocation type OI2 (Add) or 1 12 (Replace + CSS channel), the MS-MAC may need to allocate 
additional endpoint identifiers, in a similar manner to that described in clause 23.5.4.2.2. 

NOTE 3: When the BS sends a channel allocation on a CSS channel, it should include a higher layer message 

indicating the intended usage of the channel allocation except in some cases of allocation type IO2 (Quit). 
Even if only an LLC acknowledgement is included with the channel allocation, this may enable the MS to 
deduce the intended usage. 

23.5.4.3 Channel change 
23.5.4.3.1 Timing of channel change 

When the MS -MAC obeys a channel allocation command, it shall inform the lower layers of any change of RF carrier 
and/or timeslot(s) and/or bandwidth and/or modulation mode - using the TMV -CONFIGURE request primitive. The 
carrier information is contained in the "channel allocation" element (see clause 21). 

For a change of carrier within the cell, the MS shall assume that the current frame and slot synchronization apply also 
on the new carrier. 

When directed to a new cell, the MS-MAC shall assume the frame and slot synchronization from the SYNC and 
SYSINFO PDUs most recently received while scanning the main carrier of that cell (see clause 23.7). On receiving the 
TMC-SELECT indication primitive for a cell change channel allocation, the MLE returns a TMC-SELECT response 
primitive indicating the main carrier of the new cell, enabling the MAC to reference the correct information. 

If a "basic slot granting" or "multiple slot granting" element is included in the same PDU as the channel allocation 
element then: 

• if element "position of grant" in the PDU indicates "Current Channel", the MS shall obey the procedure for use 
of reserved slots (see clause 23.5.2) on the current channel; 

• otherwise the MS shall assume that the slot grant is on the allocated channel. 

NOTE 1 : If the MS does not obey the channel allocation, it may use any subslot or slot(s) that are granted on the 
current channel but ignores a slot grant if element "position of grant" in the PDU indicates the allocated 
channel. 

The timing of the move to an allocated channel shall be as follows: 

1) If the MS obeys an individually addressed channel allocation, or if it makes an immediate decision to obey a 
group addressed channel allocation, then the first uplink (respectively downlink) slot on the allocated channel 
shall be defined relative to either: 

a) the end of the downlink slot containing the channel allocation; or 

b) in the case of a channel allocation with a slot grant on the current channel (with "granting 
delay" ;^ 11 II2): 

■ the end of the last uplink slot granted by that PDU (or the end of the slot containing a granted 
subslot or, for a multiple slot grant, the end of the last slot containing a granted subslot); or 

c) if the current channel is a multi-slot channel, and the next immediate uplink slot following the channel 
allocation is part of the current channel, and the MS is transmitting traffic in that slot or was previously 
granted that slot (or a subslot in that slot) for reserved access: 

■ the end of that next immediate uphnk slot; 
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whichever is the later; see note 2. Then, after one timeslot duration, the first uplink (respectively downlink) 
slot on the allocated channel shall be defined as the next uplink (respectively downlink) slot that corresponds 
to one of the timeslots indicated by element "timeslot assigned". This timing rule shall apply both for 
allocation within the same cell and for a different cell. 

NOTE 2: For the purposes of this procedure, the time of the end of the slot is defined as being just less than one 

timeslot duration after the start of that slot (i.e. the time of the end of the slot is regarded as occurring an 
instant before the start of the next slot), where the start of the slot is as specified in clauses 7, 9.4.3.4 
and 9.4.7.4. This applies even though, in case a), the MS may need to receive the downlink beyond the 
"end of the downlink slot" in order to decode that downlink slot. Also, after switching, the MS may need 
to start receiving the downlink before the start of the first slot on the allocated channel in order to decode 
that slot. 

For a slot grant on the allocated channel, granting delay = OOOO2 in the "basic slot granting" element (or in the 
first "basic slot granting" element in a "multiple slot granting" element) shall refer to the use of the first uplink 
slot on the allocated channel. Granting delay > OOOO2 shall then refer to delaying by the specified number of 
delay opportunities on the allocated channel as defined by element "timeslot assigned". 

NOTE 3: Condition b) may apply for a channel allocation with either a basic slot grant or a multiple slot grant on 
the current channel. In either case, condition b) refers to the end of the last uplink slot in which either the 
whole slot or a subslot is granted by that PDU. 

NOTE 4: Condition c) above applies only to a frequency full duplex or fast switching MS. It assumes that the MS 
cannot stop transmission immediately and should not stop in the middle of a full slot. For example, if the 
MS is transmitting traffic and receives a channel allocation sent in downlink slot 1, the MS should 
continue to transmit in the immediately following uplink slot 4 (if that is a valid traffic slot), before 
moving to the allocated channel. 

NOTE 5: The following are examples of the channel timing, for allocation within the same cell. 

i) For a channel allocation sent in slot 1, assigning timeslot 1, e.g. on another RF carrier: 

the first uplink slot on the allocated channel is the uplink slot 1 of the same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 1 of the next TDMA 
frame. 

ii) For a channel allocation sent in slot 1, assigning timeslot 2: 

the first uplink slot on the allocated channel is the uplink slot 2 of the same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 2 of the next TDMA 
frame. 

iii) For a channel allocation sent in slot 1, assigning timeslot 4: 

the first downlink (respectively uplink) slot on the allocated channel is the downlink 
(respectively uplink) slot 4 of the same TDMA frame (i.e. frame number X where the 
channel allocation was sent in slot 1 of frame X). 

iv) For a channel allocation sent in slot 1, with a single subslot grant on the current channel in that 
TDMA frame, and assigning timeslot 1 : 

the first downlink (respectively uplink) slot on the allocated channel is the downlink 
(respectively uplink) slot 1 of the next TDMA frame. 

v) For a channel allocation sent in slot 1, with a single subslot grant on the current channel in that 
TDMA frame, and assigning timeslot 2: 

the first downlink (respectively uplink) slot on the allocated channel is the downlink 
(respectively uplink) slot 2 of the next TDMA frame. 
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vi) For a channel allocation sent in slot 1, with a single subslot grant on the current channel in that 
TDMA frame, and assigning timeslot 3: 

the first uplink slot on the allocated channel is the uplink slot 3 of the same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 3 of the next TDMA 
frame. 

vii) For a channel allocation sent in slot 1, with a single subslot grant on the current channel in that 
TDMA frame, and assigning timeslots 1 and 4: 

the first uplink slot on the allocated channel is the uplink slot 4 of the same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 1 of the next TDMA 
frame. 

viii) If a frequency full duplex or fast switching MS is transmitting traffic on a multi-slot channel 

comprising timeslots 1, 2 and 3, and receives a channel allocation sent in slot 2 of a frame in the 
range 1 to 17, replacing the current channel with timeslots 2, 3 and 4, then the MS continues to 
transmit traffic in uplink slot 1 before it switches channel. Then: 

the first uplink slot on the allocated channel is the uplink slot 3 of the same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 2 of the next TDMA 
frame. 

ix) If the MS is on a two-slot channel conprising timeslots 2 and 3, and receives a channel allocation 
sent in slot 2 of frame X, with a multiple slot grant for slot 2 of the current TDMA frame (frame X) 
and slot 3 of the next TDMA frame but one (frame X + 2), and assigning timeslots 2, 3 and 4: 

the first downlink slot on the allocated channel is the downlink slot 3 of frame X H- 3; 

the first uplink slot on the allocated channel is the uplink slot 2 of frame X H- 3. 

For allocation on a different cell, the MS still allows one timeslot duration (approximately 14,167 ms). 
Then the first uplink (respectively downlink) slot on the allocated channel on the new cell is the next 
uplink (respectively downlink) slot that corresponds to one of the timeslots indicated by element "timeslot 
assigned" - using the new cell synchronization. This timing applies whether the new cell is synchronized 
to the current cell or not. The normal rules for slot grants and CLCH(-Q) permission then apply on the 
allocated channel. 

NOTE 6: Element "position of grant" is included to allow flexibility of channel scheduling by the BS. For example, 
if there is already traffic on the uplink of the allocated channel, the BS may wish to grant a subslot on the 
current channel for a layer 2 acknowledgement from an MS that is to receive traffic, e.g. in case of 
independent allocation of uplink and downlink. In other cases, granting on the allocated channel may 
often be more appropriate. 

When using the layer 2 acknowledged service, the BS should grant a subslot on the current channel for 
the layer 2 acknowledgement from the MS when sending a channel allocation that the MS may choose to 
"reject". This is because, if the BS granted a subslot on the allocated channel and the MS did not move to 
the allocated channel, then the MS could not use the granted subslot on the allocated channel for the 
layer 2 acknowledgement. 

2) If the MS decides to obey a group addressed channel allocation after a delay then the first uplink (respectively 
downlink) slot on the allocated channel shall be defined either relative to the time when the MS -MAC receives 
the TMC-CONFIGURE request primitive accepting the channel allocation or relative to the end of the slot in 
which the MS-MAC received the TMC-CONFIGURE request primitive. Then, after one timeslot duration, the 
first uplink (respectively downlink) slot on the allocated channel shall be defined as the next uplink 
(respectively downlink) slot that corresponds to one of the timeslots indicated by element "timeslot assigned". 
This timing rule shall apply both for allocation within the same cell and for a different cell. 
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For a slot grant on the allocated channel, the granting delay is defined relative to the first uplink slot on the 
allocated channel for an immediate decision (as specified in procedure 1) above). Therefore, in the case of a 
delayed decision, the MS -MAC shall not use the granted capacity unless it is capable of calculating the 
intended time of the granted capacity based on an immediate decision and the higher layers accept the channel 
allocation before that time occurs. If the MS-MAC does not use the granted capacity then, since uplink 
messages with a group address in the MAC header are only ever sent by reserved access, the MS should 
discard the uplink message intended to be sent in the granted capacity. 

EXAMPLE: In an implementation, the MS-MAC could issue a MAC-READY signal for the group address and 
receive the TMA-UNITDATA request primitive but then report failure to send the message. 

NOTE 7: Uplink messages with the group address in the MAC header are used only for the low-level group 
presence indication. 

Slot granting is valid only on the channel on which the grant was made, except in the case of slots granted in the same 
PDU as a channel allocation and with element "position of grant" indicating the allocated channel. Therefore, after an 
MS has obeyed a channel allocation command then, if it is no longer using the channel on which the channel allocation 
was received, any slot grants received on the old channel before the channel allocation shall cease to be valid. 

As defined in clauses 23.4.2.1 and 23.4.3.1, fragmentation and reconstruction apply to a specific control channel. 
Therefore, after an MS has obeyed a channel allocation command then, if it is no longer using the channel on which the 
channel allocation was received, it shall discontinue any ongoing uplink fragmentation on the old channel (reporting to 
the LLC that the transmission has failed) and shall also discard any partially reconstructed downlink TM-SDU. 

23.5.4.3.2 Use of "timeslot assigned" 

If the "timeslot assigned" element ^ OOOO2, the MS-MAC shall note that the channel is an assigned channel, assigned 
for SCCH or for a circuit mode call. If the "timeslot assigned" element = OOOO2, the MS shall go to the appropriate 
common control channel as indicated by the last received SYSINFO or SYSINFO-Q PDU. 

An assigned channel may comprise one or more timeslots per TDMA frame, as indicated by the bit map in element 
"timeslot assigned". 

For "allocation type" = II2 (i-C- Replace + CSS channel), the "timeslot assigned" element shall indicate only those slots 
belonging to the assigned channel. Thus, if the specified carrier is not the main carrier, the first bit in the bit map shall 
be (bit map = OXXX2); the use of slot 1 for the CSS channel is implicit. If the specified carrier is the main carrier, the 
bit corresponding to the common channel shall be 0. 

NOTE: The designation of whether the MS-MAC regards the channel as "assigned" or "common" affects the 
random access and channel maintenance procedures. 

If the BS assigns slot 1 of the main carrier for a circuit mode call, it should send a channel allocation 
command to those users. This does not cause a change of carrier or timeslot; but it is needed to change the 
MAC mode from "common" to "assigned", and also to define monitoring pattern information and a traffic 
usage marker. A similar procedure applies if the BS wishes to allow an MS that is receiving a CSS 
channel to use slot 1 of that carrier for a circuit mode call or as a fully assigned SCCH. 

23.5.4.3.3 Use of "up/downlink assigned" and "Up/downlink assigned for 
augmented channel allocation" 

The "Up/downlink assigned" element in the channel allocation is used in two ways: 

• values 01 2, IO2 and 11 2 indicate whether either or both directions on the allocated channel have been assigned 
exclusively for the usage required by the MS; 

• value OO2 indicates that this is an augmented channel allocation; then conditional element "Up/downlink 
assigned for augmented channel allocation" indicates whether either or both directions on the allocated channel 
have been assigned exclusively for the usage required by the MS. 

The MS-MAC shall note, from element "Up/downlink assigned" or "Up/downlink assigned for augmented channel 
allocation", whether either or both directions on the allocated channel have been assigned exclusively for the usage 
required by the MS. 
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This information generally affects only the channel maintenance procedure. In the case of independent allocation of 
uplink and downlink for different purposes, reduced procedures shall apply; see clause 23.5.6. 

However, for the application of the general procedures for transmission and reception of signalling messages, each 
control channel (ACCH or SCCH) shall be assumed to occupy any control slots on both the downlink and uplink 
directions, as indicated by element "timeslot assigned". 

EXAMPLE: The MS attempts to receive and decode the downlink channel according to the normal procedures 
for an assigned channel, even if only the uplink was allocated by element "Up/downlink assigned" 
or "Up/downlink assigned for augmented channel allocation". Similarly, the normal procedures for 
random access and reserved access on an assigned channel apply, even if only the downlink was 
allocated by element "Up/downlink assigned" or "Up/downlink assigned for augmented channel 
allocation". 

NOTE 1: The up/downlink assigned designation (from either element) is included to allow the BS to use 

independent allocation of uplink and downlink i.e. allocating the uplink and downlink channels for 
different purposes (as described in clause 23.3.4). 

NOTE 2: For "allocation type" = 1 12, the up/downlink assigned designation applies only to the assigned channel. 
Allocation of only one direction of a CSS channel does not apply. 

MSs that support D8PSK and/or QAM operation need to support the augmented channel allocation. It is optional 
whether an MS that only supports 3i/4-DQPSK operation supports the augmented channel allocation. If an MS that does 
not support augmented channel allocations receives a channel allocation with the "Up/downlink assigned" element set 
to OO2, the MS-MAC shall discard the channel allocation and any TM-SDU carried in the MAC-RESOURCE or 
MAC-END PDU that contained the channel allocation. 

The currently defined values of the "Up/downlink assigned for augmented channel allocation" element are values OI2, 
IO2 and 1 12; value OO2 is reserved in the present document. If the MS-MAC receives an augmented channel allocation 
with the "Up/downlink assigned for augmented channel allocation" element set to OO2, it shall discard the channel 
allocation and any TM-SDU carried in the MAC-RESOURCE or MAC-END PDU that contained the channel 
allocation. 

23.5.4.3.4 CLCH(-Q) permission 

If the "CLCH(-Q) permission" flag indicates "Immediate CLCH(-Q) permission" and the MS makes an immediate 
decision to accept the channel allocation then the MS may use the first subslot of the first uplink slot on the allocated 
channel for linearization, without needing to receive the corresponding ACCESS-ASSIGN PDU. The first uplink slot 
on the allocated channel is as defined in procedure 1) of clause 23.5.4.3.1 i.e. as defined for an immediate decision. The 
MS uses CLCH if the allocated channel is a 7i/4-DQPSK or D8PSK channel, or CLCH-Q if the allocated channel is a 
QAM channel. 

Otherwise, if the MS requires to use CLCH or CLCH-Q for linearization, it shall wait for an appropriate frame 18 or for 
an ACCESS-ASSIGN PDU indicating a linearization subslot. 

NOTE 1 : The "CLCH(-Q) permission" flag is included to allow for fast call set-up with a change of RF carrier 

while still allowing flexibility for the BS, e.g. in cases of independent allocation of uplink and downlink 
or repeat set-up signalling for a group call. The BS should at least give CLCH(-Q) permission to any MSs 
that need to use CLCH or CLCH(-Q) for linearization and that are granted slots and/or given transmit 
permission on a new carrier. The CLCH(-Q) permission applies to any MS that obeys the channel 
allocation message without delay, whether or not it has been granted slots and/or transmit permission. 

NOTE 2: For "allocation type" = 1 12, the CLCH(-Q) permission applies only to the assigned channel, not to the 
CSS channel. 

NOTE 3: In the case of a delayed decision to accept a group addressed channel allocation, the MS may use the 
CLCH(-Q) permission if it is capable of calculating the time of the first uplink slot of the allocated 
channel based on an immediate decision and the higher layers accept the channel allocation before that 
time occurs. 
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23.5.4.3.5 Monitoring pattern information 

The MS shall note the monitoring pattern information in case it is required to transmit user traffic on this channel. This 
requirement to store the monitoring pattern information applies to any MS that obeys the channel allocation message, 
whether or not it has been given permission to transmit user traffic at this time. 

The monitoring pattern information indicates in which downlink frames the MS is required to receive downlink slots 
and attempt to decode any signalling messages (within the capabilities of that MS) while it is transmitting traffic. This 
enables the BS to send signalling messages to that MS during its traffic transmission. See clause 9 for the definition of 
the usage of the monitoring pattern numbers; see also clause 21.5.2. 

In the case that no monitoring pattern is assigned, an additional field defines the multiframes in which the MS shall 
receive and attempt to decode the downlink assigned slot in frame 18 (or, for a multi-slot channel, at least the highest 
numbered downlink slot of the assigned channel in frame 18). 

The requirements for the MS to adhere to the assigned monitoring pattern(s) are only within the capabilities of that MS. 
The BS should note those capabilities when sending signalling messages to an MS that is transmitting traffic on a 
multi-slot channel (see clauses 23.3.1.3 and 23.3.1.4). 

NOTE 1 : When the BS allocates a multi-slot channel to a frequency half duplex MS, it is not precluded from 

assigning monitoring pattern(s) that the MS cannot observe. For example, this may be convenient if the 
BS assigns the monitoring pattern information in a group addressed channel allocation, where the group 
contains both frequency full duplex and frequency half duplex MSs. However the BS should be aware 
that a frequency half duplex MS without fast switching capability is not able to receive signalling on the 
downlink between transmitted bursts on the uplink. 

NOTE 2: The monitoring pattern information refers to the requirements on an MS that is transmitting traffic to 

receive the downlink of the current channel. This is not the same as the "monitoring procedure" defined in 
clause 23.7.4, in which the MS measures the signal strength of adjacent cells or sectored channels (or the 
main carrier of the serving cell) and calculates C2. 

NOTE 3: The BS designer should note that the assignment of all three monitoring patterns to a frequency half 
duplex MS in a simplex call may reduce that MS's ability to perform cell reselection measurements on 
adjacent cells while it is transmitting traffic. The BS designer should also note that the assignment of all 
three monitoring patterns to a frequency half duplex dual watching MS may reduce that MS's ability to 
perform dual watch on the Direct Mode RF carrier during Vh-D calls. 

NOTE 4: For "allocation type" = 1 12, the monitoring pattern information applies only to the assigned channel, not 
to the CSS channel. 

23.5.4.3.6 Bandwidth, modulation mode and related parameters 

The "channel allocation" element allows the BS to make an augmented channel allocation. An augmented channel 
allocation is indicated by setting the "Up/downlink assigned" element to OO2. 

If the channel allocation is not augmented (i.e. element "Up/downlink assigned" i^ OO2), the MS shall assume that the 
allocated channel is a 25 kHz 3i/4-DQPSK conforming channel and that the BS transmit power on the allocated channel 
relative to the main carrier is dB. 

If the channel allocation is augmented (i.e. element "Up/downlink assigned" = OO2), elements "bandwidth of allocated 
channel" and "modulation mode of allocated channel" shall indicate the bandwidth of the allocated channel and whether 
the allocated channel is a ji/4-DQPSK, D8PSK or QAM channel. 

If the allocated channel is a QAM channel, the "maximum uplink QAM modulation level" element shall indicate the 
maximum modulation level that the MS is permitted to use on the uplink. If the MS does not understand the value of the 
"maximum uplink QAM modulation level" element, it shall regard the value as indicating the maximum QAM 
modulation level supported by that MS. 

Then the "conforming channel status" element shall indicate whether the allocated channel is a conforming channel, 
non-conforming concentric channel or sectored channel. 
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NOTE 1: As described in clause 23.7, a "concentric channel" has essentially the same azimuthal radiation pattern as 
the main carrier and is radiated from the same site as the main carrier. A "conforming channel" is a 
concentric channel that has essentially the same range as the main carrier. A "non-conforming concentric 
channel" is a concentric channel that has a larger or smaller range than the main carrier. A "sectored 
channel" has a different azimuthal radiation pattern from the main carrier, and is radiated from the same 
site as the main carrier; it is a non-conforming channel. 

The "BS link imbalance" element contains information that may be used by the MS in its link adaptation algorithm if 
the allocated channel is a D8PSK or QAM channel (see clause 23.4.9). The "BS transmit power relative to the main 
carrier" element shall indicate the BS transmit power (ERP) on the allocated channel. 

NOTE 2: In the case of a 7i/4-DQPSK or D8PSK channel, the bandwidth of the allocated channel is 25 kHz. In the 
case of a QAM channel, the bandwidth of the allocated channel may be 25 kHz, 50 kHz, 100 kHz or 
150 kHz. 

NOTE 3: For "allocation type" = 1 12, the "modulation mode of allocated channel" information applies only to the 
assigned channel, not to the CSS channel; a CSS channel is always a 7i/4-DQPSK channel. Use of 
"allocation type" 1 12 is not appropriate when the BS is allocating a QAM channel. 

23.5.4.3.7 Napping status and napping information 

If the channel allocation is augmented (i.e. element "Up/downlink assigned" = OO2), the "napping status" element shall 
indicate whether napping is permitted on the allocated channel: 

• if "napping status" = OO2, the MS shall assume that use of the napping procedure is not permitted on the 
allocated channel; 

• if "napping status" = OI2, the MS shall assume that use of the napping procedure is permitted on the allocated 
channel, using the napping parameters specified in the "napping information" element; 

• if "napping status" = IO2, the MS shall assume that use of the napping procedure is permitted on the allocated 
channel, using the napping parameters for the current channel (i.e. the channel on which the channel allocation 
was received). 

If the channel allocation is not augmented (i.e. element "Up/downlink assigned" i^ OO2), the MS shall assume that use of 
the napping procedure is not permitted on the allocated channel. 

NOTE 1: Napping may apply only on an assigned channel. It does not apply on the MCCH or a common SCCH. 

NOTE 2: For "allocation type" = 1 12, the "napping status" and "napping information" apply only to the assigned 
channel, not to the CSS channel. Use of the napping procedure does not apply on a CSS channel. 

23.5.4.3.8 Elements following napping status and napping information 

If the channel allocation is augmented (i.e. element "Up/downlink assigned" = OO2), the channel allocation includes the 
following elements following the "napping status" or "napping information" element: 

• a four-bit reserved element; 

• a flag indicating whether a first 16-bit conditional element is present, and the conditional element if 
appropriate; 

• a flag indicating whether a second 16-bit conditional element is present, and the conditional element if 
appropriate; 

• a flag indicating further augmentation of the channel allocation (allowing for future further extension). 

These elements allow for inclusion of future information in the channel allocation. 

The four-bit reserved element and two 16-bit conditional elements allow for inclusion of future information in the 
channel allocation, while still allowing MSs that do not understand that information to process and obey the channel 
allocation. The four-bit reserved element (and 16-bit conditional elements if present) are set to zero in the present 
document. However the MS may continue to process the channel allocation and any TM-SDU carried in the 
MAC-RESOURCE or MAC-END PDU, and obey the channel allocation, if these elements are not set to zero. 
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The farther augmentation flag allows for inclusion of future additional information whose size is not defined in the 
present document. The further augmentation flag shall be set to in the present document. If the MS receives a channel 
allocation with the further augmentation flag set to 1, it shall discard the channel allocation and any TM-SDU carried in 
the MAC-RESOURCE or MAC-END PDU that contained the channel allocation. 

23.5.5 Usage marker assignment 

A traffic usage marker is a 6-bit MAC label used during circuit mode calls for transmitter pre-emption, for prevention 
of crossed calls and for channel maintenance purposes. The BS shall assign a traffic usage marker before any traffic 
transmission takes place on an assigned channel. 

It shall assign the usage marker with a message that contains also a channel allocation command directing MS(s) to an 
assigned channel. The usage marker assignment shall be valid for that MS (or those MSs) only on that assigned channel. 
So, for example, for message trunking, one traffic usage marker generally applies for the complete call and the same 
usage marker should be assigned for all participants in that call on that assigned channel; whereas, for transmission 
trunking, the BS should assign a traffic usage marker for each "over". 

NOTE 1 : If the BS wishes to assign a traffic usage marker on an already assigned channel, then it may use the 
"replace channel" command indicating the current channel. However, when the BS uses a group 
addressed message to allocate a channel for a circuit mode call, it is recommended that, if possible, it 
assigns the traffic usage marker when it sends the channel allocation; otherwise the usage marker may not 
be received by those MSs that do not make an immediate decision to accept the channel allocation. 

NOTE 2: For "allocation type" = 11 2, the usage marker applies only to the assigned channel, not to the CSS 
channel. 

When there is traffic (TCH or STCH) on either the uplink or the downlink, the BS shall use the appropriate traffic usage 
marker in the ACCESS-ASSIGN PDU sent on the AACH in frames 1 to 17 on the downlink assigned channel to 
confirm permission to transmit and/or receive traffic. For uplink traffic. Header 11 2 shall be used, with "Field 2" set to 
the uplink traffic usage marker. For downlink traffic. Header 01 2, IO2 or 1 12 shall be used, with "Field 1" set to the 
downlink traffic usage marker. 

A traffic usage marker may also be sent in the ACCESS-ASSIGN PDU in frame 18, though frame 18 is never used for 
TCH or STCH. Then the frame 18 Header shall be set to 1 12 and the usage marker in "Field 1" may be set to either the 
uplink or downlink traffic usage marker as appropriate. This can be useful for channel maintenance purposes. And, 
during uplink traffic, it should be used with the traffic usage marker of the transmitting MS if the BS has not assigned a 
monitoring pattern for frames 1 to 17 (or, for a multi-slot channel, if the BS has assigned monitoring pattern(s) that the 
MS may not be capable of following in any slots in frames 2 to 17). 

The procedures for channel maintenance by the MS-MAC, and the criteria for MS transmission and reception of traffic, 
are described in clauses 23.5.6 and 23.8.2 respectively. 

When the BS wishes to assign a traffic usage marker, it shall use the MAC-RESOURCE PDU, which shall contain 
"Address Type" = IIO2 and the assigned traffic usage marker. The "channel allocation" element shall be included in that 
MAC-RESOURCE PDU or in the associated MAC -END PDU. If the MS -MAC receives a usage marker assignment 
without the corresponding channel allocation (e.g. in the case of fragmentation if the MS does not receive the 
MAC-END PDU), or if it does not obey the channel allocation, then it shall ignore the usage marker assignment. 

A traffic usage marker shall apply for the direction(s) specified in the channel allocation, i.e. the appropriate direction 
for element "Up/downlink assigned" or "Up/downlink assigned for augmented channel allocation" = OI2 or IO2, or both 
directions for element "Up/downlink assigned" or "Up/downlink assigned for augmented channel allocation" = 1 12. If 
the BS uses independent allocation of the uplink and downlink for two circuit mode calls then the traffic usage marker 
should be different for the two directions. 

In the case of independent allocation of the uplink and downlink of a channel for concurrent calls involving the same 
MS, the MS-MAC may receive independent channel allocations of uplink and downlink, each with a usage marker 
assignment. Each usage marker shall apply independently for the specified direction. (However, the same endpoint 
identifier applies for both allocations when the allocations are for the same assigned channel.) 
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The MS-MAC shall consider that an assigned traffic usage marker is valid until: 

i) it leaves the assigned channel (or returns to common mode on this channel); or 

ii) it receives another traffic usage marker with a channel allocation for the same direction(s) or for both 
directions on the same assigned channel; or 

iii) it receives a channel allocation for the same direction(s) or for both directions on the same assigned channel, 
but without a usage marker assignment. 

The BS is responsible for deciding when a traffic usage marker may safely be re-used for a subsequent call on the same 
physical channel. 



23.5.6 Maintenance of assigned cinannel 



The MS shall receive the MCCH, or the appropriate common SCCH, unless directed by the BS to an assigned channel. 
An assigned channel may be intended for secondary control purposes or for a circuit mode call. The MS shall assume 
that the assigned channel is intended for secondary control unless it has received a traffic usage marker for use on the 
channel. 

The ACCH is the control channel associated with an assigned traffic channel. When ACCH is present, its usage is 
similar to the usage of assigned SCCH, and there is no distinction in the pre-set usage marker designation in the 
ACCESS-ASSIGN PDU. Both types of control channel shall be regarded as assigned control channel. The traffic usage 
marker is generally used only while the channel is carrying user traffic TCH or STCH. 

The procedures for channel maintenance defined in clause 23.5.6.1 apply on either type of assigned channel, unless 
specified otherwise. 

The procedures for maintenance of a CSS channel are reduced compared with those for a normal assigned channel. 
They are defined in clause 23.5.6.2. 

23.5.6.1 Criteria for leaving assigned channel 

The MS-MAC shall continue to receive and attempt to decode signalling on the downlink assigned channel as defined 
by element "timeslot assigned" (within the constraints of the napping procedures and the cell reselection procedures, 
and monitoring pattern requirements, and linearization and transmission requirements) until one of the following 
occurs: 

• the MS-MAC obeys a channel allocation command from the BS, directing it elsewhere (see clause 23.5.4); or 

• the MS is required to leave the channel by one of the channel maintenance procedures in clauses 23.5.6. 1 . 1 
and 23.5.6.1.2; or 

• the MS-MAC receives a TMC-SELECT request primitive from the higher layers instructing it to leave the 
assigned channel; or 

• the MS-MAC receives a TMC-CONFIGURE request primitive from the higher layers indicating call release 
for this channel, e.g. the user wishes to leave a group call. 

In the last case, the MS should not leave the channel if it has been assigned both directions of the channel in two 
independent allocations of uplink and downlink, and if the service on the other direction is still ongoing. 

23.5.6. 1 . 1 Checking of AACH or AACH-Q 

The MS shall attempt to decode: 

• the AACH, on a 7i/4-DQPSK or D8PSK channel; or 

• the AACH-Q, on a QAM channel, 

in slots appropriate to the downlink assigned channel as defined by element "timeslot assigned" (within the constraints 
of the napping procedures and the cell reselection procedures, and monitoring pattern requirements, and linearization 
and transmission requirements). 
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The AACH always contains the ACCESS-ASSIGN PDU. The AACH-Q may contain the ACCESS-ASSIGN PDU 
(depending on the value of the AACH-Q mode element - see clause 21.4.7.1). 

If N.208 successive ACCESS-ASSIGN PDUs received in frames 1 to 17 in the AACH or AACH-Q of slots appropriate 
to the downlink assigned channel indicate that: 

a) the downlink is unallocated, i.e. Header t- OO2 and downlink usage marker = UMx (OOOOOO2); or 

b) the channel has returned to exclusively common control use, i.e. Header = OO2; or 

c) the relevant direction(s) have been assigned for another purpose (see below), 

then the MS shall regard the assigned channel as no longer valid for transmission or reception. Then, if the MS does not 
have a concurrent assigned channel, it shall return to the main carrier, i.e. to the MCCH or appropriate common SCCH. 
The MS-MAC shall inform the higher layers of the de-allocation using either: 

• the TMA-RELEASE indication primitive to indicate loss of the connection; or 

• a TMC-CONFIGURE indication primitive indicating loss of the physical resource, 

and shall inform the higher layers of any change of channel using the TMC-SELECT indication primitive. 

NOTE 1 : When the LLC receives the TMA-RELEASE indication primitive, it locally disconnects any advanced 
links on that resource (see clause 22.3.3.4). When the LLC receives the TMC-CONFIGURE indication 
primitive indicating loss of the physical resource, it may retain any advanced links on that resource for 
potential continuation (see clause 22.3.5). 

For criterion c), the MS shall check as follows: 

• If the downlink was assigned for this MS (element "Up/downlink assigned" or "Up/downlink assigned for 
augmented channel allocation" = OI2 or 11 2), the MS shall regard the assigned channel as no longer valid if: 

for a 7I/4-DQPSK or D8PSK assigned SCCH: 

the downlink is not in assigned control i.e. the channel is no longer valid if Header = OO2 or if the 
downlink usage marker t- 000001 2; 

for a QAM assigned SCCH: 

the channel is no longer valid if Header = OO2 or if the downlink usage marker is neither 000001 2 nor 
00001 12 (see note 8); 

for a circuit mode call: 

the downlink is not in assigned control nor in traffic with the MS's usage marker i.e. the channel is no 
longer valid if Header = OO2 or if the downlink usage marker is neither 000001 2 nor the MS's downlink 
traffic usage marker. 

• If the uplink was assigned for this MS (element "Up/downlink assigned" or "Up/downlink assigned for 
augmented channel allocation" = IO2 or 1 12), the MS shall regard the assigned channel as no longer valid if: 

for assigned SCCH: 

the uplink is unallocated or is being used for traffic i.e. the channel is no longer valid if Header =112 ^^id 
the upUnk usage marker = OOOOOO2 or is > OOOIOO2; 

for a circuit mode call: 

the uplink is unallocated or is being used for traffic by other users i.e. the channel is no longer valid if 
Header = 1 12 and the uplink usage marker = OOOOOO2 or is > OOOIOO2 and is not the MS's uplink traffic 
usage marker. 
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If the MS has been assigned both directions of the channel in two independent channel allocations then it shall not leave 
the channel on criterion c) unless both directions are no longer valid according to the above definition. Whereas, if the 
MS has been assigned both directions of the channel in a single channel allocation (i.e. with element "Up/downlink 
assigned" or "Up/downlink assigned for augmented channel allocation" = 1 12) then it shall leave the channel on 
criterion c) if either direction is no longer valid. 

NOTE 2: The MS should not react to reception of only one adverse ACCESS-ASSIGN PDU, because of the 
possibiHty of incorrectly decoding the AACH or AACH-Q. So N.208 > 2. 

NOTE 3: The value of N.208 may be different on a QAM channel from the value on a 7i/4-DQPSK or 
D8PSK channel. 

NOTE 4: The N.208 procedure refers to a check on those ACCESS-ASSIGN PDUs that are received by the MS, 
irrespective of whether or not these are in successive slots on the assigned channel. On a 7i/4-DQPSK or 
D8PSK channel, the MS does not receive the ACCESS-ASSIGN PDU in a downlink slot if the AACH is 
not decodeable. On a QAM channel, the MS does not receive the ACCESS-ASSIGN PDU in a downUnk 
slot if either the AACH-Q is not decodeable or the ACCESS-ASSIGN PDU is not present within the 
AACH-Q. 

NOTE 5: For this procedure, the MS checks only the designation of slots belonging to the downlink assigned 
channel (although, in the case of an extended random access channel, the MS may be decoding other 
ACCESS-ASSIGN PDUs). 

NOTE 6: As a result of de-allocation on criterion b) or c), the MS may actually remain on the same physical 
channel. However, its designation has changed from "assigned" to "common". 

NOTE 7: If the BS has assigned only the uplink in a channel allocation, and the downlink is not used for another 
purpose, the BS should mark the downlink as "assigned control" in the ACCESS-ASSIGN PDU, not 
"unallocated". Similarly, the BS should not use Header OO2 unless the channel is entirely dedicated to 
common control usage. 

NOTE 8: Downlink usage marker 00001 12 is reserved in the present document. However it may be used on a QAM 
assigned SCCH in future editions of the present document. Therefore the MS is required to regard value 
00001 12 as a valid downlink usage marker on a QAM assigned SCCH. 

23.5.6.1.2 Inactivity time-out 

If the MS is on a channel assigned for SCCH, and a time T.208 elapses without either: 

• transmission by the MS by reserved access; or 

• receipt of a downlink message on this channel containing one of its valid addresses or event labels, other than 
the predefined broadcast group address (all ones), 

then the MS shall regard the channel as no longer valid for transmission or reception. 

If the MS is on a channel assigned for a circuit mode call, and a time T.209 elapses without either: 

• transmission by the MS, for traffic (TCH or STCH) or by reserved access; or 

• receipt of a downlink message on this channel containing one of its valid addresses or event labels, other than 
the predefined broadcast group address (all ones); or 

• receipt of an ACCESS-ASSIGN PDU containing the MS's traffic usage marker (either as the downlink or the 
uplink usage marker in the ACCESS-ASSIGN PDU, and in any frame I to 18), 

then the MS shall regard the channel as no longer valid for transmission or reception. 
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In case of time-out on either T.208 or T.209 then, if the MS does not have a concurrent assigned channel, it shall return 
to the main carrier, i.e. to the MCCH or appropriate common SCCH. The MS-MAC shall inform the higher layers of 
the de-allocation using either: 

• the TMA-RELEASE indication primitive to indicate loss of the connection; or 

• a TMC-CONFIGURE indication primitive indicating loss of the physical resource, 

and shall inform the higher layers of any change of channel using the TMC-SELECT indication primitive. 

NOTE 1: In order to keep MSs on the channel during long periods of FACCH, e.g. for an open channel, the BS 
may send occasional slots in frames 1 to 17 containing the traffic usage marker as the uplink usage 
marker (with Header 11 2); or it may use the traffic usage marker as the usage marker in frame 18 
(frame 18 Header 1 12). Also, use of the traffic usage marker as the downlink usage marker in occasional 
slots in frames 1 to 17 (with STCH + STCH) is not precluded though it is not recommended. Otherwise 
the BS could send dummy messages addressed to the MS(s) on the channel. 

NOTE 2: If the MS decides to obey a group addressed channel allocation after a delay then it may choose to 

decrease its value of T.208 or T.209 until it has received signalling confirming that the expected service is 
still ongoing on the assigned channel i.e. until it has received an appropriate downlink message addressed 
to itself or ACCESS-ASSIGN PDU(s) containing its traffic usage marker. Similarly, in clause 23.5.6.1.1, 
the MS is not precluded from reducing its value of N.208 though it should not reduce N.208 to below 2. 

23.5.6.2 Criteria for leaving carrier specific signalling channel 

After assignment of a CSS channel, the MS-MAC may continue to use the CSS channel on that carrier until one of the 
following occurs: 

a) it obeys a channel allocation command received on that CSS channel, directing it elsewhere (see 
clause 23.5.4.2.4); or 

b) it has no assigned channel on that carrier, assigned either for SCCH or for a circuit mode call; or 

c) it obeys a channel allocation command allocating slot 1 of that carrier as an assigned channel. 

The MS-MAC should inform the higher layers of the de-allocation of the CSS channel and of any change of channel. 

EXAMPLE: In criterion a), the MS leaves the CSS channel if it obeys a "replace" channel allocation received 
on the CSS channel, or if it obeys a "replace + CSS channel" allocation received on the CSS 
channel and assigning a different carrier, or if it receives and does not ignore a "quit" channel 
allocation received on the CSS channel. 

Criterion b) requires the MS to leave the CSS channel when it no longer has an assigned channel 
(other than the CSS channel) on that carrier. 

If criterion c) occurs, the MS remains on the same physical channel (i.e. slot 1 of the carrier). 
However, its usage of the physical channel has changed from CSS channel to assigned channel. 

NOTE 1 : Criterion a) only requires the MS to leave the CSS channel. It does not require the MS to leave the 

assigned channel that was allocated in the same channel allocation as the CSS channel (unless the MS is 
no longer capable of receiving that assigned channel as a result of obeying the channel allocation 
command). 

NOTE 2: Criterion b) requires the MS to leave the CSS channel when it has no assigned channel on that carrier. 
Thus the permission to use the CSS channel is not specifically linked to the assigned channel that was 
allocated in the same channel allocation as the CSS channel. If the MS leaves that assigned channel then 
it may continue to use the CSS channel if it has another assigned channel on the carrier. 
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23.5.6.3 Traffic on downlink for other users 

When the MS is receiving a 3i/4-DQPSK assigned channel, the downlink may be used for traffic independently of any 
usage of the uplink for signalling or traffic. For example: 

• uplink assigned for SCCH, but with downlink not dedicated to SCCH; 

• inter-site circuit mode call. 

An MS is specifically instructed when it may process received user traffic TCH for transfer to its U-plane application, 
as described in clause 23.8.2. 

An MS that has not received such authorization shall interpret the downlink slots as follows. 

The MS shall assume that a downlink slot in frames 1 to 17 is in traffic mode carrying traffic for other MSs if the 
ACCESS-ASSIGN PDU contains a downlink traffic usage marker (i.e. Header t- OO2 and downlink usage 
marker > OOOIOO2). Otherwise it shall assume that the downlink is in signalling mode. If the ACCESS-ASSIGN PDU is 
not received then the MS shall assume that the downlink is in the mode indicated by the last ACCESS-ASSIGN PDU 
received in frames 1 to 17 in a slot appropriate to the downlink assigned channel. (See clause 19 for the configuration in 
signalling and traffic mode.) 

In both signalling and traffic mode, full (SF = 0) or half slot (SF = 1) downlink transmissions may be used. The slot flag 
(SF) shall correspond to a change between two training sequences, as described in clause 9. 

In the case of signalling mode on a 7i/4-DQPSK channel: 

a) The MS shall interpret slots with SF = as SCH/F. 

b) The MS shall interpret slots with SF = 1 as SCH/HD H- SCH/HD. 
In the case of traffic mode on a 7i/4-DQPSK channel: 

a) The MS shall interpret slots with SF = as TCH, and shall ignore that TCH. 

b) For SF = 1, the MS shall interpret the slot as STCH H- TCH or STCH H- STCH, depending on the content of the 
first STCH. 

For STCH, the MS shall inspect the MAC header of each PDU in order to: 

discover whether the second half slot is stolen; 

perform PDU dissociation (in the case of C-plane stealing); 

process any C-plane messages addressed to itself. 

See clause 23.8.4.2.2 for the method for reception of STCH. 

The MS shall ignore the TM-SDU in any MAC-U-SIGNAL PDUs, and the TCH. 

Slots containing the synchronization training sequence shall always be interpreted as BSCH H- SCH/HD. 

Traffic mode applies only to frames 1 to 17. Both MS and BS shall always be in signalling mode on frame 18. 

NOTE 1: The above procedure applies to any MS that does not have authorization or "N.213 permission" (see 

clause 23.8.2.3.2) to receive TCH with this traffic usage marker. This includes an MS that is transmitting 
traffic in simplex mode, or an MS with a different traffic usage marker, or an MS on assigned SCCH. 

NOTE 2: When the BS changes the designation of the downlink channel, it may choose to send a few slots using 
normal training sequence 2 (i.e. SF = 1), to allow for poor reception of the ACCESS-ASSIGN PDU. MS 
interpretation of SCH/HD and two-half-slot STCH is very similar. At other times, use of SCH/F (with 
PDU association) is recommended for most C-plane signalling on the downlink, since it is generally more 
flexible. 
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23.5.7 Maintenance of common channel 

The MS shall attempt to decode the AACH in slots appropriate to the downlink common channel (within the constraints 
of the cell reselection procedures and energy economy or dual watch mode). 

If N.215 successive ACCESS-ASSIGN PDUs received in frames 1 to 17 in the AACH of slots appropriate to the 
downlink common channel indicate that: 

• the downlink is unallocated, i.e. header value = II2 and "field 1" = UMx (OOOOOO2) and 
"field 2" = UMx (OOOOOO2), 

then the MS should regard the common channel as no longer valid for transmission or reception. The MS-MAC should 
inform the higher layers of the de-allocation using the "common channel deallocated" TMC-REPORT indication 
primitive (indicating a downlink failure) in order to initiate the MLE cell reselection procedures (as indicated in 

clause 18.3.4.5.3). 

23.6 PDU transfer for broadcast messages (TMB-SAP) 
23.6.1 Broadcast logical channels 

The BS shall transmit broadcast system information on phase modulation carriers (i.e. carriers currently carrying 
7I/4-DQPSK and/or D8PSK channel(s)) using the SYNC PDU transmitted on the BSCH and the SYSINFO PDU 
transmitted on the BNCH. 

NOTE 1: The ACCESS-DEFINE PDU also contains broadcast information relating to random access and is 
described within clause 23.5.1. 

On a phase modulation traffic or control channel, the BSCH and BNCH shall be transmitted in frame 18. The BNCH 
may also be transmitted during frames 1 to 17 of a control channel, and both BSCH and BNCH may be transmitted on 
unallocated channels. The precise rules for BSCH and BNCH transmission are described in clause 9. 

BSCH and BNCH shall be received and decoded by all MSs camped on a cell. These broadcast PDUs contain essential 
system information required by the MS to synchronize with and use the facilities of the system. An MS, on receiving 
and correctly decoding broadcast information, shall remove the MAC header and shall store the parameters contained 
therein as the serving cell broadcast parameters. (While scanning adjacent cells, the MAC may also be required to store 
the broadcast parameters for those adjacent cells for use in the cell reselection procedures.) The MAC shall then pass 
the TM-SDU to the MLE. Upon receiving subsequent BSCH or BNCH PDUs, the MAC shall update its stored serving 
cell parameters before passing the MLE data contained in the TM-SDU to the LLC which shall then pass the MLE data 
transparently to the MLE. The appropriate MAC primitives are TMB-SYNC indication and TMB-SYSINFO indication. 

NOTE 2: In addition to the TM-SDU, the TMB-SYSINFO indication primitive may include extended services 

information from the MAC PDU. For example, any information in the SYSINFO PDU about support of 
data priority by the BS is used by the MAC but is also used by the higher layers (e.g. SNDCP). 

The broadcast information in both of these PDUs relates to the system configuration for that cell. Therefore, the BSCH 
and BNCH information transmitted on all carriers belonging to a single cell shall be identical (with the exception of the 
items in note 3). This means that the MS may receive the system information on any phase modulation carrier 
belonging to a cell. This includes slot, frame and multiframe number implying that all carriers belonging to a BS shall 
be synchronized in time (see also clause 7). 

NOTE 3: The power control and cell/channel (re-)selection parameters may be different for different channels; see 
clause 23.6.6. Also the random access parameters may be different on different channels. 

The BS may transmit broadcast system information on QAM carriers (i.e. carriers currently carrying QAM channel(s)) 
using the SYSINFO-Q PDU transmitted on the BNCH-Q using SCH-Q/D; see clause 23.6.5. The BNCH-Q may be 
transmitted in any slot in frames 1 to 18: in the present document, there is no fixed mapping of BNCH-Q on a QAM 
channel. Also, in the present document, there is no QAM broadcast synchronization logical channel. 
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23.6.2 Acquiring cell synchronization 



An MS shall synchronize with a cell by first attempting to synchronize with the synchronization training sequence 
contained in the synchronization burst (BSCH). On acquiring synchronization, the MS shall then decode the contents of 
the SYNC PDU also contained in the synchronization burst. The SYNC PDU shall contain the colour code, which shall 
be used by the MS to de-scramble the contents of all other bursts transmitted by that BS, and the system code, which 
shall indicate whether the system is a TETRA V+D system (or whether this is a Direct Mode transmission). The SYNC 
PDU shall also contain the slot, frame and multiframe number for this downlink slot giving the MS full synchronization 
with this BS. The SYNC PDU shall also contain some information about the discontinuous mode of operation of the BS 
for phase modulation carriers. 

The MS may acquire cell synchronization on any phase modulation downlink carrier being transmitted by the BS for 
that cell. The BSCH information shall be the same for all carriers within a cell, and the slot, frame and multiframe 
synchronization shall be the same. 

Having synchronized with a cell, the MS shall continue to decode subsequent SYNC PDUs transmitted by that BS but 
shall only use those with the correct colour code to prevent an MS from using the BSCH transmitted by an adjacent cell. 

NOTE: There is no other co-channel interference protection on the BSCH. 

The MS shall store the information received in the SYNC PDU and shall update this stored information on receiving 
subsequent SYNC PDUs. 



23.6.3 Acquiring network information 



An MS, having acquired cell synchronization by receiving and decoding the BSCH information, is able to decode all 
7I/4-DQPSK downlink bursts transmitted by the BS. First of all, the MS shall search for the BNCH in order to receive 
and decode the SYSINFO PDU containing system information for this cell. The SYSINFO PDU contains information 
about the frequency of the main carrier, the number of common secondary control channels in operation on the main 
carrier, information used for power control and cell (re-)selection (parameters MS_TXPWR_MAX_CELL, 
RXLEV_ACCESS_MIN, ACCESS_PARAMETER and RADIO_DOWNLINK_TIMEOUT) and some random access 
parameters (see clause 21 for full description). The MAC shall decode the SYSINFO PDU and store the MAC 
parameters. On receiving subsequent SYSINFO PDUs, the MAC shall update the stored parameters accordingly. 

Having decoded the SYNC and SYSINFO PDUs, the MS may locate the location of the MCCH (i.e. slot 1 of the main 
carrier) or the relevant common SCCH. The MS has all of the information needed to communicate with the BS and may 
now receive downlink PDUs and transmit uplink PDUs using the procedures defined elsewhere within the MAC 
protocol. 

23.6.4 Receiving SYNC and SYSINFO PDUs on D8PSK channel 

On a D8PSK channel, the BS shall transmit the BSCH (containing the SYNC PDU) and BNCH (containing the 
SYSINFO PDU) in frame 18 according to the mapping described in clause 9, and using 7i/4-DQPSK bursts. The 
SYSINFO PDU may also be transmitted in other slots in frame 18 and in frames 1 to 17, in which case the BS may use 
either a 7i/4-DQPSK burst or a 31/8-D8PSK burst. 

The SYNC and SYSINFO PDUs shall be received and decoded by all MSs using a D8PSK channel. The MS shall use 
the same procedures as described in clauses 23.6.1, 23.6.2 and 23.6.3 with the following exception: 

• parameters MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 

RADIO_DOWNLINK_TIMEOUT are specific to that D8PSK channel (see clause 23.6.6); therefore, on 
receipt of the SYSINFO PDU on a D8PSK channel, the MS shall not overwrite the equivalent stored 
parameters received on a 7i/4-DQPSK or QAM channel (or received on a concurrent D8PSK channel). 

NOTE: When the MS first acquires cell synchronization and network information (using the procedure described 
in clauses 23.6.2 and 23.6.3), if the BNCH was received on a D8PSK channel then the MS's first stored 
values of parameters MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER 
and RADIO_DOWNLINK_TIMEOUT will be the values for the D8PSK channel - which may be 
different from the values for a conforming 7i/4-DQPSK channel. However, when the MS moves to the 
MCCH or the relevant common SCCH, it will receive the values for a conforming 7i/4-DQPSK channel 
when it receives the SYSINFO PDU on that channel and will update the stored parameters accordingly. 
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23.6.5 Receiving SYSINFO-Q PDU on QAM cinannel 

In the present document, there is no QAM broadcast synchronization logical channel. There is a QAM broadcast 
network logical channel BNCH-Q (containing the SYSINFO-Q PDU), which the BS may transmit on SCH-Q/D in any 
slot in frames 1 to 18 of a QAM channel. In the present document, there is no fixed mapping of BNCH-Q on a QAM 
channel. 

The SYSINFO-Q PDU shall be received and decoded by all MSs using a QAM channel. An MS, on receiving and 
correctly decoding the SYSINFO-Q PDU, shall remove the MAC header and shall store the parameters contained 
therein. The MAC shall then pass the TM-SDU to the MLB. Upon receiving subsequent SYSINFO-Q PDUs on that 
channel, the MAC shall update its stored parameters before passing the MLE data contained in the TM-SDU to the LLC 
which shall then pass the MLE data transparently to the MLE. The appropriate MAC primitive is the 
TMB-SYSINFO-Q indication. 

NOTE: In addition to the TM-SDU, the TMB-SYSINFO-Q indication primitive may include extended services 
information from the MAC PDU. 

The SYSINFO-Q PDU contains information about the frequency of the main carrier, the number of common secondary 
control channels in operation on the main carrier, information used for power control and cell (re-)selection or assigned 
channel replacement, an encryption parameter, some random access parameters and the extended services broadcast 
element (see clause 21 for full description). 

The information about the frequency of the main carrier, the number of common secondary control channels in 
operation on the main carrier, encryption and extended services transmitted within the SYSINFO-Q PDU shall be 
identical to the equivalent information in the SYSINFO PDU transmitted on phase modulation carriers within that cell. 
Therefore the MS shall update these stored parameters whenever it receives either a SYSINFO or SYSINFO-Q PDU. 

However, parameters MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT are specific to that QAM channel (see clause 23.6.6). Therefore, on receipt of the 
SYSINFO-Q PDU, the MS shall not overwrite the equivalent stored parameters received on a 7i/4-DQPSK or D8PSK 
channel (or received on a concurrent QAM channel). 

The BS does not send the colour code, timeslot number, frame number, multiframe number or hyperframe number on a 
QAM channel. Therefore, when the MS is on a QAM channel, it shall use the colour code last received in a SYNC PDU 
on a phase modulation channel within that cell. Also it shall derive its timeslot, frame, multiframe and hyperframe 
numbering from that last received in SYNC and SYSINFO PDUs on a phase modulation channel within that cell. This 
implies that all QAM carriers belonging to a BS shall be synchronized in time with the phase modulation carrier(s); see 
clause 7 for details of the synchronization of phase modulation carriers and QAM carriers. 

Also the BS does not send any information about the discontinuous mode of operation (or U-plane DTX or frame 18 
extension); therefore, when the MS is on a QAM channel, it shall assume that the last information received in SYNC 
and SYSINFO PDUs within that cell still applies on phase modulation carriers. 

23.6.6 Power control and cell/clnannel reselection parameters 

The power control and cell (re-)selection or assigned channel replacement parameters MS_TXPWR_MAX_CELL, 
RXLEV_ACCESS_MIN, ACCESS_PARAMETER and RADIO_DOWNLINK_TIMEOUT are broadcast by the BS: 

• in the SYSINFO PDU broadcast by the BS on the BNCH on a 7i/4-DQPSK or D8PSK channel; 

• in the SYSINFO-Q PDU broadcast by the BS on the BNCH-Q on a QAM channel. 

Parameters MS_TXPWR_MAX_CELL and ACCESS_PARAMETER are used in the open loop power control 
procedure (see clause 23.4.4.2). Parameters MS_TXPWR_MAX_CELL and RXLEV_ACCESS_MIN are used in the 
calculation of the path loss parameter for the current channel on the serving cell, and for adjacent cells by scanning, and 
for the main carrier of the serving cell by monitoring (see clause 23.7). RADIO_DOWNLINK_TIMEOUT is used for 
assessing the quality of the downlink of the current channel on the serving cell (see clause 23.7.3). 

The values of parameters MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT may vary according to the modulation mode and bandwidth of the channel and 
according to whether the channel is conforming, non-conforming concentric or sectored (see clause 23.7 for the 
definition of conforming, concentric and sectored channels). 
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23.6.6.1 TT/4-DQPSK channel 

When the MS first acquires a main carrier or receives a channel allocation for a 7i/4-DQPSK channel on a new cell, the 
MS-MAC shall use the values of MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT obtained when it acquired network information by receiving the SYSINFO PDU on 
that cell (see clause 23.6.3). 

When the MS is sent to a new 7i/4-DQPSK channel within the cell, or when it returns to the MCCH or a common 
SCCH, the MS-MAC shall use the values of MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, 
ACCESS_PARAMETER and RADIO_DOWNLINK_TIMEOUT last received on a conforming 7i/4-DQPSK channel in 
that cell. 

In either case, on receiving subsequent SYSINFO PDUs on the 7i/4-DQPSK channel, the MS-MAC shall update the 
MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT parameters for that channel accordingly. 

23.6.6.2 D8PSK channel 

When the MS is sent to a D8PSK channel, the MS-MAC shall make the following assumptions about the values of 
MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT until updated by receiving SYSINFO PDUs on that channel: 

• If the MS-MAC has previously received the SYSINFO PDU on a D8PSK channel in that cell, it shall assume 
that the values of MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT are equal to those last received on a D8PSK channel in that cell. 

• Otherwise (i.e. if the MS-MAC has not previously received the SYSINFO PDU on a D8PSK channel in that 
cell) the MS-MAC shall use the values of MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, 
ACCESS_PARAMETER and RADIO_DOWNLINK_TIMEOUT last received on a conforming 7i/4-DQPSK 
channel in that cell. 

In either case, on receiving a SYSINFO PDU on the D8PSK channel, the MS-MAC shall update the 
MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT parameters for that channel accordingly. 

23.6.6.3 QAM channel 

When the MS is sent to a QAM channel with RF bandwidth B, the MS-MAC shall make the following assumptions 
about the values of MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT until updated by receiving SYSINFO-Q PDUs on that channel: 

• If the MS-MAC has previously received the SYSINFO-Q PDU on a QAM channel in that cell with the same 
bandwidth B, it shall assume that the values of MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, 
ACCESS_PARAMETER and RADIO_DOWNLINK_TIMEOUT are equal to those last received on a QAM 
channel in that cell with bandwidth B. 

• Otherwise (i.e. if the MS-MAC has not previously received the SYSINFO-Q PDU on a QAM channel in that 
cell with the same bandwidth B): 

a) the MS-MAC shall use the values of MS_TXPWR_MAX_CELL, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT last received on a conforming ji/4-DQPSK channel in that cell; 
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b) the MS-MAC shall use a value of RXLEV_ACCESS_MIN equal to: 

RXLEV_ACCESS_MIN(main) + CONVERSION_FACTOR (23.4) 

where RXLEV_ACCESS_MIN(main) is the value of RXLEV_ACCESS_MIN last received on a 
conforming 7i/4-DQPSK channel in that cell and: 

CONVERSION_FACTOR = -3 dB if the bandwidth B of the QAM channel is 25 kHz; 

CONVERSION_FACTOR = dB if the bandwidth B of the QAM channel is 50 kHz; 

CONVERSION_F ACTOR = 3 dB if the bandwidth B of the QAM channel is 100 kHz; 

CONVERSION_F ACTOR = 5 dB if the bandwidth B of the QAM channel is 150 kHz. 

In either case, on receiving a SYSINFO-Q PDU on the QAM channel, the MS-MAC shall update the 
MS_TXPWR_MAX_CELL, RXLEV_ACCESS_MIN, ACCESS_PARAMETER and 
RADIO_DOWNLINK_TIMEOUT parameters for that channel accordingly. 

23.7 Layer management communication (TIVIC-SAP) 

Clauses 23.7.1 to 23.7.5 describe procedures that the MAC performs as a service to the MLE for: 

• estimation of the radio path loss on the current channel(s) on the serving cell; 

• measurements of the quality of the link on the current channel(s) on the serving cell; 

• if the MS is not currently receiving a conforming channel: assessment of the path loss on the main carrier of 
the serving cell (based on the measurements made on the current channel); 

• on request of the MLE: 

a) assessment of the path loss for channel classes on the serving cell based on the measurements made on 
the current channel; 

b) neighbour cell monitoring i.e. monitoring of the main carrier on adjacent cells; 

c) sectored channel monitoring i.e. monitoring of sectored carriers on the serving cell or on adjacent cells; 

d) scanning of the main carrier on adjacent cells; 

e) main carrier monitoring i.e. monitoring of the main carrier on the serving cell. 

In cases b) and d), the MLE may also request assessment of the path loss for channel classes on the adjacent 
cell (based on the measurements made on the monitored or scanned main carrier on the adjacent cell). In 
case e), the MLE may also request assessment of the path loss for channel classes on the serving cell (based on 
the measurements made on the main carrier). 

Then clause 23.7.6 defines procedures for energy economy mode, and clause 23.7.7 defines procedures for selection of 
dual watch mode with energy economy group. 

The following points may be noted (see clause 18): 

• A "concentric channel" has essentially the same azimuthal radiation pattern as the main carrier and is radiated 
from the same site as the main carrier. It may use a different modulation mode, RF bandwidth and RF power 
from the main carrier and may have a larger or smaller range and coverage area than the main carrier (i.e. it 
may be a non-conforming channel). Where the BS offers multiple concentric channels with different RF 
characteristics, a concentric channel with a higher RF bandwidth will generally have a shorter range. 

• A "channel class" is defined as a set of values indicating the general RF characteristics of a concentric channel. 
The MS predicts the performance of channel(s) corresponding to a channel class from measurements made on 
another carrier on that cell (i.e. the current channel or the main carrier on the serving cell, or the main carrier 
on an adjacent cell), together with the characteristics of that channel class. A cell may offer more than one 
concentric channel or carrier belonging to the same channel class. 
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• A "conforming channel" is a special case of a concentric channel. It has essentially the same azimuthal 
radiation pattern as the main carrier, is radiated from the same site as the main carrier and has essentially the 
same range (as measured by the CI path loss parameter) as the main carrier. A channel that is not a 
conforming channel is called a non-conforming channel. 

• A "sectored channel" has a different azimuthal radiation pattern from the main carrier, and is radiated from the 
same site as the main carrier. It is a non-conforming channel. The MS cannot predict the performance of a 
sectored channel by measurements made on any other channel; it discovers which sectored channels it can use 
by monitoring each sectored carrier. 

NOTE: The present document does not support use of carriers that are not radiated from the same site as the main 
carrier. 

• If the MS is not receiving a conforming channel, the MAC estimates the performance of the main carrier on 
the serving cell from measurements made on the current channel. Additionally the MLE may request that the 
MAC performs main carrier monitoring; this may apply particularly if the MS is receiving only sectored 
channel(s), but is also permitted when the MS is receiving a non-conforming concentric channel (see 
clause 18). 

• When assessment of channel classes on the serving cell is required: 

the MLE may request assessment of the path loss for those channel classes based on the measurements 
made on the current channel; this process is referred to as serving cell channel class assessment; 

alternatively (or additionally), the MLE may request main carrier monitoring with assessment of the path 
loss for those channel classes based on the measurements made on the main carrier; this process is 
referred to as main carrier monitoring with assessment of channel classes. 

Main carrier monitoring with assessment of channel classes may apply particularly if the MS is receiving only 
sectored channel(s), but is not precluded when the MS is receiving a concentric channel (see clause 18). 

• When assessment of channel classes on an adjacent cell is required, the MLE requests neighbour cell 
monitoring or scanning of the adjacent cell main carrier with assessment of the path loss for those channel 
classes (based on the measurements made on the monitored or scanned adjacent cell main carrier); this process 
is referred to as neighbour cell channel class assessment. 

23.7.1 Path loss calculation 

The MAC layer makes signal strength measurements both autonomously on the current channel(s) on the serving cell 
and, under the control of the MLE layer, on selected neighbouring cells and on selected other carriers on the serving 
cell. The signal strength measurements shall be passed to the MLE as an approximation of radio path loss using the path 
loss parameters, CI and C2, which are defined in clauses 23.7.1.1 and 23.7.1.2. 

When the MS is not receiving a conforming channel, the MAC layer autonomously estimates the path loss C3 on the 
main carrier of the serving cell (based on the measurements made on the current channel) and passes it to the MLE. 

Also, under control of the MLE layer, the MAC layer estimates the path loss as follows and passes it to the MLE: 

• it estimates the path loss C4 for selected channel classes on the serving cell (based on the measurements made 
on the current channel); 

• it estimates the path loss C5 for selected channel classes on the serving cell (based on measurements made on 
the main carrier of the serving cell); 

• it estimates the path loss C5 for selected channel classes on adjacent cells (based on measurements made on 
the main carrier of the adjacent cell). 

The path loss parameters C3, C4 and C5 are defined in clauses 23.7.1.3, 23.7.1.4 and 23.7.1.5. 

The process of estimating the path loss on the serving cell main carrier or for a channel class (on the serving cell or an 
adjacent cell), based on measurements made on another channel or carrier radiated from the same site, is referred to as 

"assessment". 
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23.7.1 .1 Path loss parameter C1 

The MS shall calculate the path loss parameter, CI, according to the following formula: 

CI = RSSI - RXLEV_ACCESS_MIN - Max ( 0, MS_TXPWR_MAX_CELL - Pj^g ) (23.5) 

where: 

• RSSI = averaged received signal level at MS or equivalent signal quality measurement; 

• RXLEV_ACCESS_MIN = minimum permissible received level at MS on this channel; 

• MS_TXPWR_MAX_CELL = maximum MS transmit power permissible on this channel; 

• P]y[g = maximum transmit power of the MS for the modulation mode on this channel. 
CI is expressed in dB and all the other parameters in dBm. 

CI is calculated for the current channel(s) on the serving cell, and for adjacent cell main carriers by scanning. RSSI, 
therefore, is defined in the relevant clauses for serving cell measurement (see clause 23.7.3) and scanning (see 
clause 23.7.5). 

The cell selection or assigned channel replacement parameters, RXLEV_ACCESS_MIN and 

MS_TXPWR_MAX_CELL, shall be transmitted on all cells using the Broadcast Network Channel (BNCH) and QAM 
Broadcast Network Channel (BNCH-Q), and shall be decoded by the MS for CI calculation. 

After synchronization has been acquired, the serving cell measurement procedure requires that CI shall be calculated 
using the values of RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL transmitted on the current channel. The 
values of parameters RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL may vary according to the modulation 
mode and bandwidth of the channel (and according to whether the channel is conforming, non-conforming concentric or 
sectored): 

• when the MS first acquires a main carrier or receives a channel allocation for a new cell or is sent to a new 
71/4-DQPSK channel within the cell, it shall make the assumptions specified in clause 23.6.6.1 about the values 
of these parameters until updated by receiving SYSINFO PDUs on that channel; 

• when the MS is sent to a D8PSK channel, it shall make the assumptions specified in clause 23.6.6.2 about the 
values of these parameters until updated by receiving SYSINFO PDUs on that channel; 

• when the MS is sent to a QAM channel, it shall make the assumptions specified in clause 23.6.6.3 about the 
values of these parameters until updated by receiving SYSINFO-Q PDUs on that channel. 

The scanning procedures also require a calculation of CI on adjacent cells; in this case, the MS shall be synchronized to 
the adjacent cell and shall use the values of RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL transmitted on 
the main carrier of that adjacent cell in the above CI calculation. 

23.7.1 .2 Path loss parameter C2 

The MS shall calculate the path loss parameter, C2, according to the following formula: 

C2(n) = RSSI(n) - RXLEV_ACCESS_MIN_MCELL(n) 
- Max ( 0, MS_TXPWR_MAX_MCELL(n) - PMs(n) ) (23.6) 



where: 



RSSI(n) = averaged received signal level at MS or equivalent signal quality measurement on the monitored 
carrier; 

RXLEV_ACCESS_MIN_MCELL(n) = minimum permissible received level at MS on the monitored carrier; 

MS_TXPWR_MAX_MCELL(n) = maximum MS transmit power allowed on the monitored carrier; 

P]y]§(n) = maximum transmit power of the MS for the modulation mode on the monitored carrier. 
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C2 is expressed in dB and all the other parameters in dBm. (n) indicates the n'" monitored carrier. 

C2 is calculated for the main carrier on adjacent cells, by monitoring. C2 is also calculated for sectored carriers on both 
the serving cell and adjacent cells, by monitoring. C2 may be calculated for the main carrier on the serving cell, by 
monitoring. RSSI, therefore, is defined in the relevant clause for monitoring (see clause 23.7.4). 

The cell selection parameters, RXLEV_ACCESS_MIN_MCELL(n) and MS_TXPWR_MAX_MCELL(n), for the main 
carrier on adjacent cells may be transmitted in the serving cell using an MLE broadcast message 
(D-NWRK-BROADCAST PDU) on the relevant common control channel (main and/or secondary). 

In the case where these parameters are not known by the serving cell or where the MS has not received them on the 
serving cell, the MS shall use the cell selection parameters RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL 
last received on a conforming 3i/4-DQPSK channel on the serving cell as default values. These are broadcast on the 
serving cell BNCH. 

The parameters RXLEV_ACCESS_MIN_MCELL(n) and MS_TXPWR_MAX_MCELL(n), and the modulation mode 
and RF bandwidth, for sectored carriers on the serving cell or adjacent cells shall be transmitted in the serving cell using 
an MLE broadcast message (D-NWRK-BROADCAST-EXTENSION PDU). 

When performing monitoring of the main carrier of the serving cell, the MS shall use the parameters 
RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL last received on a conforming 7i/4-DQPSK channel on the 
serving cell for the C2 calculation. These are broadcast on the serving cell BNCH. 

23.7.1 .3 Path loss parameter C3 

The MAC layer autonomously calculates the path loss parameter CI for the current channel (see clause 23.7.1.1) and 
passes it to the MLE. Also, when the MS is not receiving a conforming channel, the MAC layer autonomously 
estimates the path loss C3 on the main carrier of the serving cell, based on the measurements made on the current 
channel, and passes it to the MLE. This process is referred to as assessment of the main carrier. 

NOTE: Additionally, if the MLE prefers the MAC to make direct measurements of the path loss on the main 
carrier, the MLE may request main carrier monitoring on the serving cell. 

The MS shall calculate the path loss parameter, C3, according to the following formula: 

C3 = RSSI - RXLEV_ACCESS_MIN(main) - Max ( 0, MS_TXPWR_MAX_CELL(main) - PMs(main) ) 

- BS_TXPWR_RATIO_CHANNEL (23.7) 

where: 

RSSI = averaged received signal level at MS or equivalent signal quality measurement on the current channel; 

RXLEV_ACCESS_MIN(main) = minimum permissible receive level on the common control channel; 

MS_TXPWR_MAX_CELL(main) = maximum MS transmit power allowed on the common control channel; 

P]y[§(main) = maximum transmit power of the MS for 7i/4-DQPSK modulation; 

BS_TXPWR_RATIO_CHANNEL is the BS transmit power (ERP) relative to the main carrier for the current 
channel. 

C3 and BS_TXPWR_RATIO_CHANNEL are expressed in dB and all the other parameters in dBm. 

C3 is calculated when the MS is performing serving cell measurements. RSSI, therefore, is defined in the relevant 
clause for serving cell measurement (see clause 23.7.3). 

The MS received the value of BS_TXPWR_RATIO_CHANNEL in the channel allocation that sent the MS to the 
current channel. 

The parameters RXLEV_ACCESS_MIN(main) and MS_TXPWR_MAX_CELL(main) shall be the values of 
RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL last received in the SYSINFO PDU on a conforming 
7I/4-DQPSK channel in this cell. 
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23.7.1 .4 Path loss parameter C4 

Under control of the MLE layer, the MAC estimates the values of the path loss C4 for selected channel classes on the 
serving cell, based on the measurements made on the current channel (together with the characteristics of the channel 
classes to be assessed), and passes the values of C4 to the MLE. This process is referred to as serving cell channel class 

assessment. 

NOTE: Alternatively (or additionally), when assessment of channel classes on the serving cell is required, the 
MLE may request main carrier monitoring with assessment of channel classes (see clause 23.7.1.5). 

The MS shall calculate the path loss parameter, C4, according to the following formula: 

C4(m) = RSSI - RXLEV_ACCESS_MIN_MCELL(m) - Max ( 0, MS_TXPWR_MAX_MCELL(m) - PMs(m) ) 
- ( BS_TXPWR_RATIO_CHANNEL - BS_TXPWR_RATIO_CHANNEL(m) ) (23.8) 

where: 

RSSI = averaged received signal level at MS or equivalent signal quality measurement on the current channel; 

RXLEV_ACCESS_MIN_MCELL(m) = minimum permissible receive level for the assessed channel class; 

MS_TXPWR_MAX_MCELL(m) = maximum MS transmit power allowed for the assessed channel class; 

P]y]§(m) = maximum transmit power of the MS for the modulation mode of the assessed channel class; 

BS_TXPWR_RATIO_CHANNEL is the BS transmit power (ERP) relative to the main carrier for the current 
channel; 

BS_TXPWR_RATIO_CHANNEL(m) is the BS transmit power (ERP) relative to the main carrier for the 
assessed channel class. 

C4, BS_TXPWR_RATIO_CHANNEL and BS_TXPWR_RATIO_CHANNEL(m) are expressed in dB and all the other 
parameters in dBm. (m) indicates the m™ assessed channel class. 

C4 is calculated for the appropriate channel classes when the MS is performing serving cell measurements. RSSI, 
therefore, is defined in the relevant clause for serving cell measurement (see clause 23.7.3). 

If the channel allocation that sent the MS to the current channel was an augmented channel allocation, the MS received 
the value of BS_TXPWR_RATIO_CHANNEL in the channel allocation. If the channel allocation that sent the MS to 
the current channel was not an augmented channel allocation, or if the current channel is a common control channel, the 
value of BS_TXPWR_RATIO_CHANNEL is dB. 

The parameters RXLEV_ACCESS_MIN_MCELL(m), MS_TXPWR_MAX_MCELL(m) and 

BS_TXPWR_RATIO_CHANNEL(m) and the modulation mode for the assessed channel classes shall be transmitted in 
the serving cell using an MLE broadcast message (D-NWRK-BROADCAST-EXTENSION PDU). 

23.7.1 .5 Path loss parameter C5 

When the MLE requests that the MAC performs monitoring or scanning of the main carrier on an adjacent cell, it may 
also request that the MAC estimates the values of the path loss C5 for selected channel classes on that adjacent cell, 
based on the measurements made on the main carrier of the adjacent cell (together with the characteristics of the 
channel classes to be assessed). This process is referred to as neighbour cell channel class assessment. 

When the MLE requests that the MAC performs monitoring of the main carrier on the serving cell, it may also request 
that the MAC estimates the values of the path loss C5 for selected channel classes on the serving cell, based on the 
measurements made on the main carrier of the serving cell (together with the characteristics of the channel classes to be 
assessed). This process is referred to as main carrier monitoring with assessment of channel classes. 
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The MS shall calculate the path loss parameter, C5, according to the following formula: 

C5(m,n) = RSSI(n) - RXLEV_ACCESS_MIN_MCELL(m) - Max ( 0, MS_TXPWR_MAX_MCELL(m) - PmsC™) ) 

+ BS_TXPWR_RATIO_CHANNEL(m) (23.9) 

where: 

RSSI(n) = averaged received signal level at MS or equivalent signal quality measurement on the monitored or 
scanned main carrier; 

RXLEV_ACCESS_MIN_MCELL(m) = minimum permissible receive level for the assessed channel class; 

MS_TXPWR_MAX_MCELL(m) = maximum MS transmit power allowed for the assessed channel class; 

P]y]s(m) = maximum transmit power of the MS for the modulation mode of the assessed channel class; 

BS_TXPWR_RATIO_CHANNEL(m) is the BS transmit power (ERP) relative to the appropriate main carrier 
for the assessed channel class (see note 1). 

NOTE 1: For assessment of a channel class on an adjacent cell, the appropriate main carrier is the main carrier of 
that adjacent cell; for assessment of a channel class on the serving cell, the appropriate main carrier is the 
main carrier of the serving cell. 

C5 and BS_TXPWR_RATIO_CHANNEL(m) are expressed in dB and all the other parameters in dBm. (m) indicates 
the m'" assessed channel class on the n* monitored or scanned main carrier. 

NOTE 2: The TMC-SCAN request primitive requests scanning of a single main carrier; therefore, for scanning, n is 
always 1 . The TMC-MONITOR-LIST request primitive may request monitoring of a list of main carriers. 

C5 is calculated for the appropriate channel classes when the MS is performing neighbour cell monitoring or scanning, 
or main carrier monitoring. RSSI, therefore, is defined in the relevant clauses for monitoring (see clause 23.7.4) and 
scanning (see clause 23.7.5). 

The parameters RXLEV_ACCESS_MIN_MCELL(m), MS_TXPWR_MAX_MCELL(m) and 

BS_TXPWR_RATIO_CHANNEL(m) and the modulation mode for the assessed channel classes shall be transmitted in 
the serving cell using an MLE broadcast message (D-NWRK-BROADCAST-EXTENSION PDU). 

23.7.2 Cell selection 

The MLE may instruct the MAC to select a cell, as shown in figure 23.13, using the TMC-SELECT request primitive 
which shall contain a channel number parameter corresponding to the frequency of the main carrier. The MAC shall 
then instruct the physical layer to tune to that frequency for reception. As soon as the MS MAC has acquired 
synchronization on that carrier and decoded the BSCH and BNCH for that cell, it shall confirm the cell selection, by 
sending a TMC-SELECT confirm primitive to the MLE, and begin the serving cell measurements described in the 
following clause. If the TMC-SELECT request primitive is to inform the MAC of a change to a cell which the MAC 
has previously been scanning, the MS MAC may already have acquired synchronization on the new cell and decoded 
the BSCH and BNCH contents, in which case it may respond with TMC-SELECT confirm primitive as soon as the 
physical layer has changed frequency. 

TMC-SELECT TMC-SELECT 
request confirm 



NJ^ 



MS-MAC ^ 



.J^l^ 



BS-MAC 



Figure 23.13: Cell selection 

This procedure is identical in the MAC for initial cell selection and cell reselection. 
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23.7.3 Serving cell measurement 



Having selected and acquired synchronization on a cell as described in the previous clause, the MAC shall begin 
measurement of the downlink RSSI on the current channel(s) on the serving cell, as defined in clause 23.7.3.1, and use 
this to calculate CI for the current channel(s) (see clause 23.7.1.1). It shall then periodically report CI to the MLE using 
a TMC -MEASUREMENT indication primitive as illustrated in figure 23.14. This measurement of the downlink RSSI 
and calculation of CI is known as surveillance and shall be based upon the cell selection or assigned channel 
replacement parameters (RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL) decoded on the current channel. 



TMC-SELECT 
request 



TMC-SELECT 

confirm 

TMC-MEASUREMENT 

indication (C1) 

SYNC PDU 



MS-MAC 



TMB-SYNC 
request 



SYSINFO PDU 
or SYSINFO-Q PDU 



:^l^ ^ 



TMB-SYSINFO(-Q) 
request 



BS-MAC 



Figure 23.14: Cell selection and surveillance scenario 

The MAC also performs other measurements and/or calculations relating to the performance of the serving cell: 

• If the MS is not currently receiving a conforming channel (see note), the MAC estimates the path loss C3 on 
the main carrier of the serving cell (based on the measurements made on the current channel). This calculation 
is regarded as being part of the serving cell surveillance procedure. It is described in clause 23.7.3.1.2. 

• On request of the MLE, the MAC estimates the path loss C4 for a list of channel classes on the serving cell 
(based on the measurements made on the current channel). This is described in clause 23.7.3.1.3. 

• On request of the MLE, the MAC performs monitoring of sectored carriers on the serving cell, making 
measurements on those sectored carriers and calculating the path loss C2. This is described in clause 23.7.4 
with the other monitoring functions. 

• On request of the MLE, the MAC performs monitoring of the main carrier on the serving cell, making 
measurements on the main carrier and calculating the path loss C2. This monitoring is regarded as being part 
of the serving cell surveillance procedure. It is described in clause 23.7.4 with the other monitoring functions. 

• When the MAC performs monitoring of the main carrier on the serving cell: on request of the MLE, the MAC 
also estimates the path loss C5 for a list of channel classes on the serving cell (based on the measurements 
made on the main carrier). This is described in clause 23.7.4.5. 

NOTE: If the MS is currently receiving a conforming channel, the MLE uses the value of CI for that channel as a 
criterion for serving cell radio link failure (see clause 18). If the MS is receiving a non-conforming 
channel, the MLE uses the value of CI for that channel as a criterion for current channel radio link 
failure. If the MS is currently receiving only non-conforming channel(s), the MAC estimates a path loss 
parameter C3 for the main carrier. If the MLE has not currently requested main carrier monitoring, the 
MLE uses the value of C3 as a criterion for serving cell radio link failure; if the MLE has currently 
requested main carrier monitoring, the MLE uses the value of C2 for the main carrier as a criterion for 
serving cell radio link failure. 
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23.7.3.1 Downlink measurements 

23.7.3.1 .1 Downlink measurements on current ciiannel 

23.7.3.1 .1 .1 Signal strength measurements 

The MAC shall continuously perform the measurements described in this clause on the physical channel(s) to which the 
MS is attached on the serving cell. Measurements shall be made on all downlink timeslots which the MAC attempts to 
receive within the constraints of its energy economy or dual watch mode or the napping procedures, and linearization 
and transmission requirements, or according to the monitoring pattern requirements for traffic transmission on an 
assigned channel. 

The MAC shall measure the received RF signal strength or make an equivalent signal quality measurement and 
calculate a running average of at least 5 measurement samples. 

These samples shall be taken during at least the last 5 s and at most the last 60 s. If less than 5 measurements were 
collected during this period, for example due to the constraints of an energy economy or dual watch mode, then the last 
5 measurements may be used. The measurement sample duration shall be at least SDl (see clause 10). If the BS 
operates in MCCH sharing then, when the MS is on the MCCH or a common SCCH, the measurements shall be 
performed only on the frames reserved for the BS, and not on the common frames (see clause 9). 

Based upon these measurements, the path loss parameter CI shall be calculated by the MAC at least every 5 s for the 
current channel. 

23.7.3.1 .1 .2 Radio Downlink Counter (RDC, RDC-NC or RDC-Q) 
The quality of the radio downlink shall be estimated from the success rate of decoding: 

• the AACH when the MS is receiving a 7i/4-DQPSK or D8PSK channel; or 

• the AACH-Q when the MS is receiving a QAM channel. 

The MAC shall perform the measurements described in clause 23.7.3.1.1.3, 23.7.3.1.1.4 or 23.7.3.1.1.5 to ensure that: 

• the quality on the serving cell is acceptable, in the case of measurements on a conforming 3i/4-DQPSK or 
D8PSK channel; or 

• the quality on the current channel is acceptable, in the case of measurements on a QAM channel or on a 
non-conforming 7i/4-DQPSK or D8PSK channel. 

The criterion for relinquishing the radio downlink is based on the Radio Downlink Counter (RDC, RDC-NC or 
RDC-Q). 

23.7.3.1 .1 .3 RDC on conforming n/4-DQPSK and D8PSK channels 

When the MAC first acquires cell synchronization and begins to receive the downlink of a common control channel, 
RDC shall be initialized to a value equal to RADIO_DOWNLINK_TIMEOUT. The RADIO_DOWNLINK_TIMEOUT 
parameter is broadcast on the BNCH. 

If the MAC is unable to decode an AACH, RDC shall be decreased by N x N.210. (N.210 is a constant which defines 
the quality threshold for the MS on a 7i/4-DQPSK or D8PSK channel.) In the case of a successful reception of an 
AACH, RDC shall be increased by N but shall not be increased above the value of RADIO_DOWNLINK_TIMEOUT. 

The parameter N is equal to the number of timeslots between successive downlink slots which the MS is attempting to 
receive and decode (except if the BS operates in MCCH sharing, see note 4); therefore, N is dependent on the MS mode 
of operation. Some examples are listed below. 

NOTE 1 : The parameter N includes the downlink slot that the MS is attempting to receive and decode, in addition 
to the gap between downlink slots that the MS attempts to receive and decode. 

a) MS in normal mode: 

In this mode, the MS is receiving the MCCH or a common SCCH and so listens to one slot per TDMA frame. 
Therefore, in this case, N = 4. 
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b) MS in an energy economy or dual watch mode: 

In this mode, the MS is not receiving all downlink slots of the common control channel. 

EXAMPLE: For example, an MS operating with an energy group, EG5, may only be attempting to receive and 
decode one downlink slot per multiframe. In this case, N = 72. 

c) MS receiving on an assigned channel: 

In this mode, the MS is receiving one or more timeslots per TDMA frame depending upon the number of slots 
assigned to that channel. In this case, N = 4 / number of timeslots per TDMA frame assigned to that channel 
on the downlink. 

d) MS in napping mode on an assigned channel: 

In this mode, the MS is not receiving all downlink slots of the assigned channel. 

EXAMPLE: For example, if an MS on a multi-slot assigned channel is only required to attempt to receive and 
decode one slot per TDMA frame when in napping mode then N = 4 when in napping mode. 

e) MS transmitting traffic on a single-slot assigned channel: 

In this mode, the MS is transmitting on the uplink and is receiving the downlink according to the monitoring 
pattern(s) given at channel assignment. In this case, N = 12 / number of monitoring patterns allocated to the 
MS. This applies when 1, 2 or 3 monitoring patterns are assigned. 

When the mode of operation of the MS is changed, the corresponding value of N shall be calculated by the MAC and 
used for updating RDC. 

A single RDC is valid for all conforming 7i/4-DQPSK and D8PSK channels on the cell, whatever the RF channel on 
which the MS decodes the AACH. Thus, if the MS moves to another conforming 7i/4-DQPSK or D8PSK channel, the 
RDC shall continue to run without re-initialization. If the MS moves to a non-conforming 3i/4-DQPSK or D8PSK 
channel, or to a QAM channel, the MAC shall store the current value of RDC; then, when the MS returns to reception 
of a conforming 7i/4-DQPSK or D8PSK channel, the MAC shall resume updating of that RDC (using the usual value of 
N i.e. it shall not re-calculate the value of N taking account of the additional time since the last reception on a 
conforming 7i/4-DQPSK or D8PSK channel). 

NOTE 2: The BS should indicate the same value of the RADIO_DOWNLINK_TIMEOUT parameter on all 
conforming 7i/4-DQPSK and D8PSK channels on the cell. 

Radio downlink failure shall be declared when the RDC falls below 0. If this happens, the MAC shall inform the MLE 
that radio downlink failure has occurred using a TMC-REPORT indication primitive. 

NOTE 3: N.210 controls the AACH message error rate threshold at which radio downlink failure occurs on a 

7I/4-DQPSK or D8PSK channel. For example, if N.210 = 4, the ratio 4 to 1 between failure and success 
counting gives a decreasing RDC when the message error rate exceeds 20 %. Therefore, a continuing 
message error rate greater than 20 % will cause radio downlink failure in this case. 

NOTE 4: If the BS operates in MCCH sharing, the MS uses only the frames reserved for the BS to update RDC 

(though it attempts to receive and decode the relevant slot also in the common frames). Therefore, in this 
case, for an MS in normal mode, N = 144 / number of reserved frames per two multiframes for the BS. 

23.7.3.1 .1 .4 RDC-NC on non-conforming n/4-DQPSK and D8PSK channels 

When the MS moves to a non-conforming 7i/4-DQPSK or D8PSK channel, the MAC shall use an independent radio 
downlink counter RDC-NC for that channel (except possibly in the case of concurrent channels; see clause 23.7.3.1.4). 
The MAC shall initiaUze the RDC-NC to a value equal to the assumed value of RADIO_DOWNLINK_TIMEOUT for 
that channel (see clauses 23.6.6.1 and 23.6.6.2), and shall start to decrease or increase RDC-NC according to failure to 
decode or successful reception of the AACH as described below. On receiving a SYSINFO PDU on that channel, if the 
value of the RADIO_DOWNLINK_TIMEOUT parameter in the SYSINFO PDU is different from the assumed value, 
the MAC shall make a correction by adding the difference between the true value and the assumed value of the 
RADIO DOWNLINK TIMEOUT to the current value of RDC-NC. 
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As in clause 23.7.3.1.1.3: 



• If the MAC is unable to decode an AACH, RDC-NC shall be decreased by N x N.210. In the case of a 
successful reception of an AACH, RDC-NC shall be increased by N but shall not be increased above the value 
of RADIO_DOWNLINK_TIMEOUT for that channel. 

• The parameter N is equal to the number of timeslots between successive downlink slots which the MS is 
attempting to receive and decode; therefore, N is dependent on the MS mode of operation. Examples c), d) 
and e) in clause 23.7.3.1.1.3 apply. When the mode of operation of the MS is changed, the corresponding 
value of N shall be calculated by the MAC and used for updating RDC-NC. 

NOTE: The parameter N includes the downlink slot that the MS is attempting to receive and decode, in addition 
to the gap between downlink slots that the MS attempts to receive and decode. 

RDC-NC is valid only for the current channel (except possibly in the case of concurrent channels; see 

clause 23.7.3.1.4). 

Radio downlink failure for the current channel shall be declared when the RDC-NC falls below 0. If this happens, the 
MAC shall inform the MLE that radio downlink failure has occurred on that channel using a TMC -REPORT indication 
primitive. 

23.7.3.1.1.5 RDC-Q on QAM channels 

When the MS moves to a QAM channel, the MAC shall use an independent radio downlink counter RDC-Q for that 
channel (except possibly in the case of concurrent channels; see clause 23.7.3.1.4). 

If the MS is moving from one conforming QAM channel to another conforming QAM channel with the same carrier 
frequency, RF bandwidth and BS transmit power relative to the main carrier, the MS may continue use of the previous 
RDC-Q without re-initialization. Otherwise the MAC shall initialize the RDC-Q to a value equal to the assumed value 
of RADIO_DOWNLINK_TIMEOUT for that channel (see clause 23.6.6.3), and shall start to decrease or increase 
RDC-Q according to failure to decode or successful reception of the AACH-Q as described below. On receiving a 
SYSINFO-Q PDU on that channel, if the value of the RADIO_DOWNLINK_TIMEOUT parameter in the SYSINFO-Q 
PDU is different from the assumed value, the MAC shall make a correction by adding the difference between the true 
value and the assumed value of the RADIO_DOWNLINK_TIMEOUT to the current value of RDC-Q. 

If the MAC is unable to decode an AACH-Q, RDC-Q shall be decreased by N x N.209. (N.209 is a constant which 
defines the quality threshold for the MS on a QAM channel.) In the case of a successful reception of an AACH-Q, 
RDC-Q shall be increased by N but shall not be increased above the value of RADIO_DOWNLINK_TIMEOUT for 
that channel. 

The parameter N is equal to the number of timeslots between successive downlink slots which the MS is attempting to 
receive and decode; therefore, N is dependent on the MS mode of operation. Examples c) and d) in clause 23.7.3.1.1.3 
apply. When the mode of operation of the MS is changed, the corresponding value of N shall be calculated by the MAC 
and used for updating RDC-Q. 

NOTE 1 : The parameter N includes the downlink slot that the MS is attempting to receive and decode, in addition 
to the gap between downlink slots that the MS attempts to receive and decode. 

RDC-Q is valid only for the current channel (except possibly in the case of concurrent channels; see clause 23.7.3.1.4). 

Radio downlink failure for the current channel shall be declared when the RDC-Q falls below 0. If this happens, the 
MAC shall inform the MLE that radio downlink failure has occurred on that channel using a TMC -REPORT indication 
primitive. 

NOTE 2: N.209 on a QAM channel is equivalent to N.210 on a 7r/4-DQPSK or D8PSK channel. It controls the 
AACH-Q message error rate threshold at which radio downlink failure occurs on a QAM channel. The 
value of N.209 may be different from the value of N.210. 
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23.7.3.1 .2 Assessment of the main carrier from a non-conforming assigned channel 

As defined in clause 23.7.3.1.1.1, having selected and acquired synchronization on a cell, the MAC begins measurement 
of the downlink RSSl on the current channel(s) on the serving cell, and uses this to calculate CI for the current 
channel(s). It then periodically reports each CI to the MLE using a TMC-MEASUREMENT indication primitive. 

When the MS is not currently receiving a conforming channel, the following additional procedure shall apply. 

When the MAC calculates CI for the current channel on the serving cell, it shall also estimate the path loss C3 on the 
main carrier of the serving cell - based on the RF signal strength or equivalent measurements made on the current 
channel (see clause 23.7.1.3). The MAC shall include the C3 result in the TMC-MEASUREMENT indication primitive 
whenever it reports CI to the MLE. 

When the MAC calculates C3, it shall use the cell selection parameters (RXLEV_ACCESS_MIN and 
MS_TXPWR_MAX_CELL) last received on a conforming 7i/4-DQPSK channel in this cell; it shall use the BS transmit 
power relative to the main carrier for the current channel, as received in the channel allocation. 

NOTE: Additionally, if the MLE prefers the MAC to make direct measurements of the path loss on the main 
carrier, the MLE may request monitoring of the main carrier on the serving cell (see clause 23.7.4). 

23.7.3.1 .3 Serving cell channel class assessment 

Serving cell channel class assessment is an MS function which uses measurements made on the current channel to 
estimate the path loss C4 for selected channel classes. The current channel may be either a conforming or 
non-conforming channel. 

Figure 23.15 illustrates how the MLE initiates the procedure for serving cell channel class assessment. The MLE sends 
a TMC-ASSESSMENT-LIST request primitive including a list of channel classes to be assessed, together with the 
characteristics of each channel class to be assessed. 

NOTE 1 : The characteristics of each channel class to be assessed include the modulation mode for that channel 
class, the maximum MS transmit power for that channel class, the minimum RX access level for that 
channel class and the BS transmit power relative to the main carrier of the serving cell. 

The MAC shall measure the received RF signal strength or equivalent on the current channel as described in 
clause 23.7.3.1.1.1. Based on these measurements, the MAC shall estimate the path loss C4 for each of the channel 
classes (see clause 23.7.1.4). The MAC shall estimate the path loss C4 for each channel class at least every 5 s. 

The result of the TMC-ASSESSMENT-LIST request primitive shall be contained in the TMC-ASSESSMENT 
indication primitive. The MAC shall estimate C4 for each channel class and shall periodically pass the results to the 
MLE using the TMC-ASSESSMENT indication primitive. 

When the MAC calculates C4 for a channel class, it shall use the values of the channel class characteristics parameters 
provided by the MLE (received by the MLE in the D-NWRK-BROADCAST-EXTENSION PDU). It shall also use the 
BS transmit power relative to the main carrier for the current channel. (This is assumed to be dB unless the current 
channel is an assigned channel allocated with an augmented channel allocation.) 

A TMC-ASSESSMENT-LIST request primitive with an empty channel class list shall inform the MAC to cease serving 
cell channel class assessment. 

NOTE 2: Alternatively (or additionally) to requesting serving cell channel class assessment, if the MLE wishes the 
channel classes on the serving cell to be assessed using measurements made on the main carrier, the MLE 
may request main carrier monitoring with assessment of channel classes (see clause 23.7.4.5). 

TMC-ASSESSMENT-LIST TMC-ASSESSMENT 

request indication (C4) 



:^i^ 



MS-MAC 



RSSl ^1^ 

^ I BS-MAC 



Figure 23.15: Scenario for serving cell channel class assessment 
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23.7.3.1 .4 Concurrent channels on the serving cell 

If the MAC is using concurrent channels on the serving cell, it shall perform the measurements and fulfil the 
requirements of providing the CI parameter to the MLE (and C3 when appropriate), and information about the channel 
quality, in a way which is equivalent to or better than the method described below. 

If the MAC is using concurrent channels, it may measure and report CI independently for each individual channel. 

Alternatively, if two or more of the concurrent channels are conforming channels with the same RF parameters, the 
MAC may make a single CI calculation for those channels, based on measurements made on the combination of those 
channels. For the purposes of this procedure, the channels may be regarded as having the same RF parameters if they 
have the same value of P^s, RXLEV_ACCESS_MIN, MS_TXPWR_MAX_CELL, BS transmit power relative to the 
main carrier, carrier frequency and RF bandwidth. 

If none of the concurrent channels is a conforming channel, the MAC is required to provide an estimate of the path 
loss C3 to the MLE (see clause 23.7.3.1.2). The MAC shall provide C3 to the MLE when it provides CI, for at least one 
of the concurrent channels. 

If the MLE initiates the procedure for serving cell channel class assessment, the MAC may use the measurements made 
on any of the current channels to estimate the path loss C4 for the selected channel classes; however, if the MS is 
currently using both concentric and sectored channel(s), the MS should use the measurements made on a concentric 
channel in preference to measurements made on a sectored channel. If two or more of the concurrent channels are 
conforming channels with the same RF parameters (as defined above), the MAC may estimate the path loss C4 based 
on measurements made on the combination of those channels. 

If the MS is using concurrent conforming 7i/4-DQPSK and/or D8PSK channels, the MAC shall use a single radio 
downlink counter RDC for those channels, as defined in clause 23.7.3.1.1.3. 

NOTE: The BS should indicate the same value of the RADIO_DOWNLINK_TIMEOUT parameter on all 
conforming 7i/4-DQPSK and D8PSK channels on the cell. 

If the MS is using concurrent non-conforming 7i/4-DQPSK and/or D8PSK channels with the same carrier frequency, BS 
transmit power relative to the main carrier and value of RADIO_DOWNLINK_TIMEOUT, the MAC may use a single 
radio downlink counter RDC-NC for those channels. 

If the MS is using concurrent conforming QAM channels with the same carrier frequency, RF bandwidth, BS transmit 
power relative to the main carrier and value of RADIO_DOWNLINK_TIMEOUT, the MAC may use a single radio 
downlink counter RDC-Q for those channels. 

If the MS is using concurrent non-conforming QAM channels with the same carrier frequency, RF bandwidth, BS 
transmit power relative to the main carrier and value of RADIO_DOWNLINK_TIMEOUT, the MAC may use a single 
radio downlink counter RDC-Q for those channels. 

Otherwise the MAC shall use separate radio downlink counters for concurrent channels. 

23.7.3.2 Uplink measurements 

The criterion for determining the relinquishment of the radio uplink in the BS may be based upon uplink received signal 
strength measurement or an equivalent signal quality measurement and a measurement of the path delay from MS to BS 
derived from the time at which uplink slots are received at the BS. 

The measurement of uplink received signal strength or quality may be used by the BS as a criterion to relinquish the 
radio link. The BS may inform the MS if this happens by sending a MAC-RESOURCE PDU which includes the 
optional "Power control" element with a value set to "Radio uplink failure". On receiving this, the MS MAC shall 
inform the MLE using a TMC-REPORT indication primitive. (The MLE action on receipt of this report depends on 
whether the current channel is a conforming channel; see clause 18.) 

The measurement of uplink path delay may also be used by the BS as a criterion to relinquish the radio link. This allows 
the BS to limit the MS-BS distance and prevent the MS grossly exceeding the planned cell boundaries. The BS may 
inform the MS if this happens by sending a MAC -RESOURCE PDU which includes the optional "Power control" 
element with a value set to "Maximum path delay exceeded". On receiving this, the MS MAC shall inform the MLE 
using a TMC-REPORT indication primitive in order to initiate the MLE cell reselection procedures. 
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23.7.4 Monitoring 



The monitoring procedure is an MS function which measures the signal strength of carriers other than the carrier of the 
current channel and calculates C2. The monitoring procedure may be used for neighbour cell monitoring, sectored 
channel monitoring and main carrier monitoring. 

Neighbour cell monitoring is an MS function which measures the signal strength of the main carrier on adjacent cells 
and calculates C2. The cell selection parameters for the adjacent cell may be broadcast on the serving cell for the C2 
calculation. Monitoring is used when the MS is not synchronized to the adjacent cells and so cannot decode the adjacent 
cell BNCH. 

For neighbour cell monitoring, when the MLE initiates the monitoring procedure in the MAC, the MLE may also 
request assessment of the path loss (C5) for a number of channel classes on an adjacent cell (using the measurements 
made on the main carrier of that adjacent cell). 

Sectored channel monitoring is an MS function which measures the signal strength of sectored carriers on the serving 
cell or on adjacent cells. The parameters for the sectored carrier are broadcast on the serving cell for the C2 calculation. 

Main carrier monitoring is an MS function which measures the signal strength of the main carrier of the serving cell and 
calculates C2. The parameters for the main carrier are broadcast on the serving cell. 

For main carrier monitoring, when the MLE initiates the monitoring procedure in the MAC, the MLE may also request 
assessment of the path loss (C5) for a number of channel classes on the serving cell (using the measurements made on 
the main carrier of the serving cell). 

The following clauses describe the monitoring procedure. The MS MAC shall perform the measurements and fulfil the 
requirements of providing the C2 parameter to the MLE in a way which is equivalent to or better than the method 
described. 

23.7.4.1 Monitoring scenario 

Figure 23.16 illustrates how the MLE initiates the monitoring procedure in the MAC by sending 
TMC-MONITOR-LIST request primitive along with a list of channel numbers which correspond to the frequencies of 
the RF channels (carriers) to be monitored. The channel numbers in the list may correspond to a combination of 
adjacent cell main carriers, serving cell sectored carriers and/or adjacent cell sectored carriers, and may include the 
main carrier of the serving cell. 

TMC-MONITOR 

TMC-MONITOR-LIST '"^'^^*'°" ^^^^ 
request (TMC-SCAN-REPORT 



/N 



:il^ 



MS-MAC 



1^ 



indication (01) ) 

RSSI M/ 



BS-MAC 



Figure 23.16: Monitoring scenario 

The result of the TMC-MONITOR-LIST request primitive shall be contained in the TMC-MONITOR indication 
primitive. The MAC shall make the measurements needed to calculate C2 for each RF channel and shall periodically 
pass the result for each one using the TMC-MONITOR indication primitive. 

The following points apply for neighbour cell monitoring: 

• The MAC shall use the adjacent cell parameters provided by the MLE for the C2 calculation (if they have been 
received on the serving cell by the MLE in the D-NWRK-BROADCAST PDU). If the MS has not received 
these, the MAC shall use the cell selection parameters last received on a conforming 3i/4-DQPSK channel on 
the serving cell to calculate C2 instead. 

• If the MS has already acquired synchronization on an adjacent cell and it has decoded the broadcast parameters 
needed to calculate CI, the MAC shall report the updated value of CI for the adjacent cell using the 
TMC-SCAN-REPORT indication primitive instead of reporting C2 for that cell. 



£75/ 



864 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

The following points apply for sectored channel monitoring: 

• For each sectored carrier to be monitored, the TMC-MONITOR-LIST request primitive indicates the 
modulation mode and the RF bandwidth. 

• The MLE provides the parameters for the C2 calculation (received on the serving cell by the MLE in the 
D-NWRK-BROADCAST-EXTENSION PDU). 

NOTE: For bandwidths greater than 25 kHz, the carrier number in the D-NWRK-BROADCAST-EXTENSION 
PDU refers to the centre frequency of the lowest 25 kHz comprising the carrier (as for a channel 
allocation, see clause 21.5.2). 

The following point applies for main carrier monitoring: 

• The MS shall use the parameters RXLEV_ACCESS_M1N and MS_TXPWR_MAX_CELL last received on a 
conforming 7i/4-DQPSK channel on the serving cell for the C2 calculation. 

A TMC-MONITOR-LIST request primitive with an empty channel list shall inform the MAC to cease monitoring. 

23.7.4.2 Monitoring measurements 

The MAC shall measure the received RF signal strength or equivalent signal quality for all RF channels (carriers) of the 
monitor list. 

As far as possible the same number of measurement samples shall be taken for all RF channels and the measurement 
samples shall be uniformly distributed over the averaging period. 

The MAC shall measure the received RF signal strength or make an equivalent signal quality measurement for all RF 
channels of the monitor list. For each RF channel, it shall calculate a running average of at least 5 measurement 
samples. These samples shall be taken during at least the last 5 s and at most the last 60 s. If less than 5 measurements 
were collected during this period, for example due to the constraints of an energy economy or dual watch mode, then 
the last 5 measurements may be used. The measurement sample duration shall be at least SDl (refer to clause 10). 
Using the average of these measurements, the MAC shall calculate the parameter C2 at least every 5 s. In the case of 
neighbour cell monitoring, the MAC may in addition calculate the parameter CI for all RF channels of the monitoring 
list with which it has already synchronized and decoded the BNCH. 

23.7.4.3 Signal strength measurement 

The RSSI measurements or equivalent signal quality measurements shall be made during the non-assigned or non-used 
timeslots of the physical channel(s) to which the MS is attached. 

EXAMPLE: - for a receiving or idle MS, during the uplink slots of the physical channel; 

for a transmitting MS, during the downlink slots not already assigned to serving cell reception 

as defined by the monitoring pattern(s) allocated to the MS; 

for an MS in full duplex, during the unused uplink slot of the control frame; 

when the MS is not transmitting, during the downlink slots in which the MS is not required to 

receive, as a result of the napping or energy economy procedures. 

The measurements shall be made whenever possible, taking into account the mode of operation and the frequency 
switching capability of the MS. However, the overall frequency of measurement, taking into account all RF channels, 
need not exceed the following rate: 

MS in half duplex RX or TX mode: 6 measurements per multiframe period; 

MS in idle mode: 1 measurement per 3 downlink slots of the MCCH or common SCCH. 

If the RF channel does not operate in timesharing mode, the measurement sample duration shall be at least SD2 as 
defined in clause 10. 

If the RF channel operates in timesharing mode and if the MS has knowledge of the timesharing synchronization, the 
MS shall perform the measurements only during the timeslots exclusively reserved to the monitored channel. If no 
active timeslots can be found that coincide with the monitoring periods, the measurement shall not be performed on this 
RF channel. If some can be found, the measurement sample duration shall be at least SDl. 
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If the RF channel operates in timesharing mode and if the MS does not have knowledge of the timesharing 
synchronization, the measurement sample duration shall be at least SDl and several measurements are allowed on the 
same RF channel during one monitoring period. The MS shall calculate the average of the 5 samples showing the 
highest RF signal strength during the preceding 10 s, these samples being separated by at least 50 ms. 

NOTE: Timesharing mode may apply for neighbour cell monitoring (indicated by the MLE in the 

TMC -MONITOR-LIST request primitive); timesharing mode may apply for main carrier monitoring 
(indicated by the SYNC PDU on the serving cell); timesharing mode does not apply for sectored channel 
monitoring. 

23.7.4.4 Neighbour cell monitoring with assessment of channel classes 

When the MLE initiates the monitoring procedure for the main carrier on an adjacent cell, it may also request 
assessment of the path loss (C5) for a number of channel classes on that adjacent cell. 

Figure 23.17 illustrates how the MLE initiates the neighbour cell monitoring procedure with assessment of channel 
classes on the adjacent cell(s). The MLE sends a TMC-MONITOR-LIST request primitive including one or more 
channel numbers, of which at least one corresponds to the frequency of an adjacent cell main carrier to be monitored. 
For each adjacent cell main carrier to be monitored, the MLE may include a list of channel classes to be assessed 
(together with the characteristics of each channel class to be assessed). 

NOTE: The characteristics of each channel class to be assessed include the modulation mode for that channel 
class, the maximum MS transmit power for that channel class, the minimum RX access level for that 
channel class and the BS transmit power relative to the main carrier of that adjacent cell. 
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Figure 23.17: Neighbour cell monitoring scenario with assessment of channel classes 

The MAC shall make the measurements needed to calculate C2 for the adjacent cell main carrier (as defined in 
clauses 23.7.4.2 and 23.7.4.3), and shall then estimate the path loss (C5) for each of the channel classes to be assessed - 
based on the RSSI or equivalent measurements made on the monitored main carrier. The MAC shall then pass the C2 
result and the C5 results to the MLE using the TMC-MONITOR indication primitive. 

The MAC shall make the measurements needed to calculate C2 for each adjacent cell main carrier and shall periodically 
pass the result for each one, and also the corresponding C5 results for each one, using the TMC-MONITOR indication 
primitive. 

The MAC shall use the adjacent cell parameters provided by the MLE for the C2 calculation (if they have been received 
on the serving cell by the MLE in the D-NWRK-BROADCAST PDU). If the MS has not received these, the MAC shall 
use the cell selection parameters last received on a conforming 7i/4-DQPSK channel on the serving cell to calculate C2 
instead. The MAC shall use the values of the channel class characteristics parameters provided by the MLE for the 
C5 calculation (received on the serving cell by the MLE in the D-NWRK-BROADCAST-EXTENSION PDU). 

If the MS has already acquired synchronization on an adjacent cell and it has decoded the broadcast parameters needed 
to calculate CI, the MAC shall report the updated value of CI for the adjacent cell using the TMC-SCAN-REPORT 
indication primitive instead of reporting C2 for that cell. In this case the MAC shall include the C5 results in the 
TMC-SCAN-REPORT indication primitive. 
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23.7.4.5 Main carrier monitoring with assessment of channel classes 

When the MLE initiates the monitoring procedure for the main carrier on the serving cell, it may also request 
assessment of the path loss (C5) for a number of channel classes on the serving cell. 

Figure 23.18 illustrates how the MLE initiates the main carrier monitoring procedure with assessment of channel classes 
on the serving cell. The MLE sends a TMC-MONITOR-LIST request primitive including one or more channel 
numbers, one of which corresponds to the frequency of the main carrier on the serving cell. The MLE also includes a 
list of channel classes to be assessed (together with the characteristics of each channel class to be assessed). 

NOTE: The characteristics of each channel class to be assessed include the modulation mode for that channel 
class, the maximum MS transmit power for that channel class, the minimum RX access level for that 
channel class and the BS transmit power relative to the main carrier of the serving cell. 
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Figure 23.18: Main carrier monitoring scenario with assessment of channel classes 

The MAC shall make the measurements needed to calculate C2 for the main carrier (as defined in clauses 23.7.4.2 and 
23.7.4.3), and shall then estimate the path loss (C5) for each of the channel classes to be assessed - based on the RSSI or 
equivalent measurements made on the main carrier. The MAC shall then pass the C2 result and the C5 results to the 
MLE using the TMC-MONITOR indication primitive. 

The MAC shall make the measurements needed to calculate C2 for the main carrier and shall periodically pass the 
result, and also the corresponding C5 results, using the TMC-MONITOR indication primitive. 

The MAC shall use the parameters RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL last received on a 
conforming 7i/4-DQPSK channel on the serving cell for the C2 calculation. The MAC shall use the values of the 
channel class characteristics parameters provided by the MLE for the C5 calculation (received by the MLE in the 
D-NWRK-BROADCAST-EXTENSION PDU). 

23.7.5 Scanning 

Scanning is an MS function which measures the signal strength on the main carrier of the adjacent cells and calculates 
CI using the adjacent cell parameters broadcast on the relevant adjacent cell. It is used when the MS is synchronized to 
the adjacent cell and is able to decode the adjacent cell BSCH and BNCH. 

When the MLE initiates the scanning procedure in the MAC, it may also request assessment of the path loss (C5) for a 
number of channel classes on that adjacent cell (using the measurements made on the main carrier of the adjacent cell). 

The following clauses describe the scanning procedure. The MS MAC shall perform the measurements and fulfil the 
requirements of providing the CI parameter to the MLE in a way which is equivalent to or better than the method 
described. 

23.7.5.1 Scanning scenario 

Figure 23. 19 illustrates how the MLE initiates the scanning procedure in the MAC by sending TMC-SCAN request 
primitive along with a channel number which corresponds to the frequency of the adjacent cell main carrier to be 
scanned and a scanning measurement method to indicate whether foreground, background or interrupted scanning is to 
be used. 

The MAC shall make the measurements needed to calculate CI for the adjacent cell RF channel (carrier) and shall pass 
the result using TMC-SCAN confirm primitive. The MS shall use the cell selection parameters broadcast on the 
adjacent cell for the CI calculation. 
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Figure 23.19: Scanning scenario 



23.7.5.2 Scanning measurement 

Scanning shall comprise of achieving synchronization with an adjacent cell, measuring the received signal strength or 
an equivalent signal quality and decoding the BSCH and BNCH broadcast on the adjacent cell. Scanning shall be 
performed on one RF channel at a time. Three different methods of scanning are defined: 

• foreground, where scanning is the only activity; 

• background, where communications with the current serving cell are maintained in parallel with the scanning, 
and the scanning causes no interruption to that service; 

• interrupting, where communications with the current serving cell are maintained in parallel with the scanning, 
but the scanning causes limited interruptions to that service. 



23.7.5.2.1 



Foreground scanning 



Foreground scanning is used when the MS is in idle mode on the serving cell and wishes to scan an adjacent cell. The 
MS switches from the serving cell main carrier to the adjacent cell main carrier. The MS then acquires synchronization 
and makes the adjacent cell measurements before returning to the serving cell main carrier. 

The MS MAC shall carry out the following in response to an MLE instruction to perform foreground scanning: 

• Change frequency to the RF channel to be scanned in the adjacent cell. 

• Attempt to acquire synchronization on the RF channel to be scanned and decode the cell selection parameters 
in BNCH. If the BNCH cannot be decoded within 5 s, the scanning shall be stopped. 

• Measure the received RF signal strength or equivalent received signal quality. These measurements shall be 
used for calculating CI. The averaging shall be calculated using at least 5 measurement samples, each sample 
having a duration of at least SD2 (as defined in clause 10). As far as possible, these samples should be evenly 
spread over at least 300 ms. 

• Calculate CI for the scanned RF channel. 

• Return to the serving cell main carrier. 

The MAC may decode the cell selection parameters at the same time as making the RSSI or equivalent measurements. 
Any measurements made within the 5 s before the start of scanning may also be used to calculate CI. 

In the case where the BS is operating in timesharing mode, the measurements shall be made during the timeslots 
exclusively reserved to the scanned channel and the number of periods may be reduced to the number of active 
timeslots over a period of two multiframes. 



23.7.5.2.2 



Bacl^ground scanning 



Background scanning is used when the MS wishes to scan an adjacent cell and maintain any current service on the 
serving cell, whether that is receiving the downlink control channel or transmitting or receiving as part of a call. The 
MS switches from the serving cell main carrier to the adjacent cell main carrier in between any transmissions or 
receptions on the serving cell. The MS attempts to acquire synchronization on the adjacent cell during those times. 

The signal strength measurements shall be identical to those performed during monitoring (see clause 23.7.4.3). 
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The MAC shall attempt to synchronize and read the BSCH and BNCH for the scanned RF channel. The MAC shall 
devote all its monitoring capability to these operations. The parameters decoded on the BNCH shall be used to calculate 
the path loss parameter CI. 

The MAC shall keep the information concerning the time synchronization for the RF channels of the list. This 
information may be used to schedule the subsequent decoding of cell selection parameters and shall be used when 
accessing a re-selected cell. 

When a new RF channel for which the MAC does not have synchronization has to be scanned, the MAC shall devote all 
its monitoring capability to synchronize on this RF channel and read the cell selection parameters contained in the 
BNCH, in priority over signal strength measurements on all other RF channels. If the cell selection parameters cannot 
be read within 15 s, a re-attempt shall not take place before Attempt_number x 15 s after the end of the last attempt 
period, Attempt_number being the number of attempts already performed. 

The MAC shall attempt to read the cell selection parameters of each of the RF channels of the list at least every minute, 
to confirm that it is monitoring the same cell and update the value of these parameters. If a change of identity is detected 
then the RF channel shall be treated as a new RF channel in the list. If the BSCH cannot be decoded, a re-attempt shall 
be made at the next available opportunity. 

For initial and subsequent cell selection parameters decoding, if the cell selection parameters cannot be decoded after 
5 attempts, its RF channel shall be discarded from the list and any existing signal strength measurements shall be 
discarded. 

The MAC shall re-calculate the parameter CI at least every 10 s for the RF channels of the list based on the updated 
measurement done by monitoring (C2). 

23.7.5.2.3 Interrupting scanning 

Interrupting scanning is similar to foreground scanning except that the MS is participating in a call on the serving cell 
and temporarily suspends service in order to scan an adjacent cell. 

The signal strength measurements shall be identical to those performed during monitoring (see clause 23.7.4.3). 

The MAC shall attempt to synchronize, read the cell selection parameters and calculate the path loss parameter CI for 
all RF channels as instructed by the MLE. 

The MAC shall devote all its resources to these operations. If the cell selection parameters cannot be read within 5 s for 
an RF channel, all signal strength measurements on this RF channel shall be discarded. 

The MAC shall keep the information concerning the time synchronization for the RF channels. This information may be 
used to schedule the subsequent decoding of cell selection parameters and when accessing a re-selected cell. Whenever 
the MAC re-calculates the parameter C2 for one of these RF channels, it shall re -calculate the parameter CI for this RF 
channel. The MAC may periodically attempt to read the cell selection parameters for these RF channels, to confirm that 
it is monitoring the same cells and update the value of these parameters. 

In the case where the radio link is relinquished before the link is declared relinquishable, the MAC shall first check all 
RF channels for which it has kept the time synchronization according to the indication given by the MLE. If none of the 
RF channels meets this criterion, the MAC shall perform the cell selection parameters measurement as for unprepared 
cell selection. 

23.7.5.3 Scanning with assessment of channel classes on adjacent cell 

When the MLE initiates the scanning procedure in the MAC, it may also request assessment of the path loss (C5) for a 
number of channel classes on that adjacent cell. 

Figure 23.20 illustrates how the MLE initiates the scanning procedure with assessment of channel classes on the 
adjacent cell. The MLE sends a TMC-SCAN request primitive along with a channel number which corresponds to the 
frequency of the adjacent cell main carrier to be scanned, a scanning measurement method to indicate whether 
foreground, background or interrupted scanning is to be used, and a list of channel classes to be assessed (together with 
the characteristics of each channel class to be assessed). 

NOTE: The characteristics of each channel class to be assessed include the modulation mode for that channel 
class, the maximum MS transmit power for that channel class, the minimum RX access level for that 
channel class and the BS transmit power relative to the main carrier of the adjacent cell. 
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The MAC shall make the measurements needed to calculate CI for the adjacent cell (as defined in clause 23.7.5.2), and 
shall estimate the path loss (C5) for each of the channel classes to be assessed - based on the RSSI or equivalent 
measurements made on the scanned main carrier. The MAC shall then pass the CI result and the C5 results to the MLE 
using TMC-SCAN confirm primitive. The MS shall use the cell selection parameters broadcast on the adjacent cell for 
the CI calculation. The MAC shall use the values of the channel class characteristics parameters provided by the MLE 
for the C5 calculation (received on the serving cell by the MLE in the D-NWRK-BROADCAST-EXTENSION PDU). 



TMC-SCAN 
request 



^^ 



TMC-SCAN 
confirm (CI, 



C5) 



MS-MAC 



SYNC PDU 



TMB-SYNC TMB-SYSINFO 
request request 



:^ ^ 



BS-MAC 



SYSINFO PDU 
Figure 23.20: Scanning scenario withi assessment of chiannel classes 



23.7.6 Selection of energy economy mode 



An MS may enter energy economy mode by negotiating with the BS. This negotiation shall be performed by an MM 
message exchange (see clause 16.7.1). Once MM has negotiated a particular energy economy group, the MAC shall be 
informed through the protocol stack using MLE-INFO request, TL-CONFIGURE request and TMC -CONFIGURE 
request primitives. These primitives shall include two parameters: 



• "Energy economy group"; and 

• "Energy economy start point". 



"Energy economy group" shall specify how long the MS may sleep between receiving downlink slots on the control 
channel and shall have one of the values shown in table 23.9. "Energy economy start point" shall specify the frame and 
multiframe number at which energy economy operation shall begin. 

Table 23.9: Definition of the Economy Groups and duration 



Economy Group 


TDMA frames to 
sleep 


EG1 


1 


EG2 


2 


EG3 


5 


EG4 


8 


EG5 


17 


EG6 


71 


EG7 


359 



An MS shall only request to enter energy economy mode while on the MCCH or a common SCCH. It shall attempt to 
receive and decode the relevant slot on the main carrier in all the TDMA frames up until and including the frame and 
multiframe given by the "Energy economy start point". The MS may then sleep for the number of TDMA frames 
indicated by the "Energy economy group". After this number of TDMA frames has elapsed, the MS shall then attempt 
to receive and decode the relevant downlink slot in the next TDMA frame. This operation (i.e. the regular cycle of 
sleeping for N TDMA frames and then receiving in one TDMA frame) shall continue while the MS remains in energy 
economy mode using this energy economy group. 

An energy economy mode shall be valid in all cells within a Registered Area (RA). If an MS changes cell within the 
RA, it may maintain the same energy economy mode and follow the same energy economy pattern after acquiring slot 
and frame synchronization on the new cell (but using the frame and multiframe numbering of the new cell). All energy 
economy groups have a cyclic energy economy pattern within a hyperframe and so, given a start point and energy 
economy group, the MS may calculate the absolute frame and multiframe numbers in which it must attempt to receive 
and decode the relevant downlink slot. Therefore, even although adjacent cells need not be synchronized, an MS may 
apply the same energy economy pattern on the new cell within the RA. 
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NOTE 1 : At the time of the cell change, the MS may need to sleep for a shorter time if there is a different 
synchronization on the new cell. The MS then reverts to the negotiated cycle. 

During energy economy mode, the MAC shall temporarily suspend the sleeping cycle if: 

• it obeys a channel allocation command allocating an assigned channel; or 

• the MS becomes active in an advanced link (see clause 18.3.5.3.3), as indicated by the MLE activity indicator 
parameter in the TMC-CONFIGURE request primitive; or 

• the MS becomes active in a call (see clause 18.3.5.3.3), as indicated by the MLE activity indicator parameter 
in the TMC-CONFIGURE request primitive; or 

• the MS has signalling messages to send; or 



• 



it receives a TMA-SAP signalling message from the BS for any of its valid addresses or event labels, other 
than the predefined broadcast group address (all ones). 



The MAC shall return to the sleeping cycle when it is on the MCCH or a common SCCH and a time T.210 has elapsed 
since: 

• the higher layers indicated no activity using the TMC-CONFIGURE request primitive; or 

• it sent its last signalling message; or 

• it last received a TMA-SAP signalling message from the BS for one of its valid addresses or event labels, other 
than the predefined broadcast group address (all ones), 

whichever is the most recent. During this time-out period, the MS shall continue to receive the downlink MCCH or 
common SCCH slot for any further signalling from the BS. 

NOTE 2: The MS may sleep only on the MCCH or a common SCCH, not on an assigned channel. 

An MS shall end energy economy mode via an exchange of MM messages with the BS. MM instructs the MAC via the 
MLE-INFO, TL-CONFIGURE and TMC-CONFIGURE request primitives and the "Energy economy group" set to 
"Stay alive" to return to receiving the common control channel during all TDMA frames. The MAC shall begin this 
immediately and so the "Energy economy start point" parameter shall have no meaning in this case. 

An MS in energy economy mode may request to change its energy economy group via an exchange of MM messages 
with the BS. From the perception of the MAC, this function is seen only as receiving an instruction from MM to end 
energy economy mode and then receiving another instruction to enter energy economy mode. 

NOTE 3: Thus, as defined for ending energy economy mode, the MAC obeys the instruction to "Stay alive" 

immediately so the "Energy economy start point" parameter has no meaning in this case. On receiving the 
instruction to enter energy economy mode, the MS continues to receive the control channel in all TDMA 
frames up until and including the frame and multiframe given by the new "Energy economy start point". 
The MS may then sleep for the number of TDMA frames indicated by the new "Energy economy group". 
After this number of TDMA frames has elapsed, the MS then receives and decodes the relevant downlink 
slot in the next TDMA frame. Operation with the new sleeping cycle (i.e. the regular cycle of sleeping for 
N' TDMA frames and then receiving in one TDMA frame) continues while the MS remains in energy 
economy mode using this energy economy group. 

If the MS is in energy economy mode and the MAC receives an instruction from MM to enter energy economy mode 
then it shall attempt to receive and decode the relevant slot on the main carrier in all TDMA frames up until and 
including the frame and multiframe given by the new "Energy economy start point". It shall then use the sleeping cycle 
defined by the new "Energy economy group". 

NOTE 4: This case may occur if the BS changes the MS's energy economy parameters. 

The MS shall end energy economy mode if it leaves the RA. 
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23.7.7 Selection of dual watch mode with energy economy group 

An MS may enter dual watch mode by negotiating with the BS. This negotiation is performed by an MM message 
exchange (see clause 16.7.2). The procedures in this clause relate to dual watch mode when the MS is using an energy 
economy group. 

NOTE 1 : A full dual watch MS is capable of periodically receiving the V+D common control channel while it is in 
a Direct Mode call (when practicable). It is also capable of periodically receiving the Direct Mode RF 
carrier while it is in a V+D call and, when idle, it periodically receives both the Direct Mode RF carrier 
and the V+D common control channel. In order for the MS to periodically receive the V+D common 
control channel while in a Direct Mode call, the MS needs to request to use an appropriate energy 
economy group when it requests to perform the full dual watching procedure. 

An MS may, alternatively, request to perform an idle dual watching procedure in which the MS may not 
be capable of receiving the V+D common control channel while it is in a Direct Mode call and may not 
be capable of receiving the Direct Mode RF carrier while it is in a V+D call. It is optional for the MS to 
request to use an energy economy group when it is performing the idle dual watching procedure. 

The procedures defined in this clause relate to the full dual watching procedure. They apply also to the 
idle dual watching procedure in the case that the MS is using an energy economy group. 

Once MM has negotiated dual watch mode with a particular energy economy group, the MAC shall be informed 
through the protocol stack using MLE-INFO request, TL-CONFIGURE request and TMC-CONFIGURE request 
primitives. These primitives shall include two parameters: 

• "Dual watch energy economy group"; and 

• "Dual watch start point". 

"Dual watch energy economy group" shall specify how long the MS may be unreachable (transmitting and/or receiving 
in Direct Mode, and/or sleeping) between receiving downlink slots on the V+D control channel and shall have one of 
the values shown in table 23.9. "Dual watch start point" shall specify the V+D frame and multiframe number at which 
dual watch mode using the agreed energy economy group shall begin. 

An MS shall only request to enter dual watch mode while on the MCCH or a common SCCH. It shall attempt to receive 
and decode the relevant slot on the main carrier if practicable (i.e. unless Direct Mode requirements take precedence), in 
all the TDMA frames up until and including the frame and multiframe given by the "Dual watch start point". The MS 
may then be unreachable (transmitting and/or receiving in Direct Mode, and/or sleeping) for the number of TDMA 
frames indicated by the "Dual watch energy economy group". After this number of TDMA frames has elapsed, the MS 
shall then attempt to receive and decode the relevant downlink slot in the next V+D TDMA frame if practicable. This 
operation (i.e. the regular cycle of being unreachable for N TDMA frames and then receiving in one V+D TDMA frame 
when practicable) shall continue while the MS remains in dual watch mode using this energy economy group. 

NOTE 2: The MS is required to attempt to receive and decode the V+D downlink slots defined in this clause only 
when practicable i.e. when Direct Mode requirements do not take precedence. When a full dual watching 
MS is a calling or called party in a Direct Mode call. Direct Mode requirements sometimes take 
precedence over V+D dual watch requirements (see EN 300 396-3 [22], clause 8.4.7.10). When an idle 
dual watching MS is a calling or called party in a Direct Mode call, the MS may not be capable of 
receiving the V+D control channel for the duration of the Direct Mode call. Therefore the BS should be 
aware that a dual watching MS will not always be able to receive in the agreed slots. (This applies also in 
the case of an MS that is performing idle dual watch without an energy economy group.) 

Also the BS should be aware that, even if the MS receives a V+D message, it may not always be able to 
send a response - even a layer 2 acknowledgement e.g. if the MS is currently in an emergency Direct 
Mode call or if the MS is in a non-emergency Direct Mode call and the BS does not grant a subslot or 
slot(s) on the current V+D channel. The BS should also be aware that, if it grants a subslot or slot(s) on 
the current V+D channel, the MS may sometimes need to use the first granted subslot for linearization 
(see clause 23.4.5). For a subslot or single-slot grant the MS should then send a response in the next 
granted subslot or slot (if this occurs within 4 multiframes). For a grant of more than one slot, the MS 
sends a response in the second granted slot. 
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Dual watch mode shall be valid in all cells within an RA. If an MS changes cell within the RA, it may maintain the 
same dual watch energy economy group and follow the same reception pattern after acquiring slot and frame 
synchronization on the new cell (but using the frame and multiframe numbering of the new cell). All energy economy 
groups have a cyclic reception pattern within a hyperframe and so, given a start point and energy economy group, the 
MS may calculate the absolute frame and multiframe numbers in which it must attempt to receive and decode the 
relevant downlink slot when practicable. Therefore, even although adjacent cells need not be synchronized, an MS may 
apply the same reception pattern on the new cell within the RA. 

NOTE 3: At the time of the cell change, the MS may need to be unreachable for a shorter time if there is a different 
synchronization on the new cell. The MS then reverts to the negotiated reception cycle. 

A dual watching MS shall temporarily revert to receiving the V+D channel in all TDMA frames if: 

• it obeys a channel allocation command allocating an assigned channel; or 

• it becomes active in a V+D advanced link (see clause 18.3.5.3.3), as indicated by the MLE activity indicator 
parameter in the TMC-CONFIGURE request primitive; or 



• 



it becomes active in a V+D call (see clause 18.3.5.3.3), as indicated by the MLE activity indicator parameter in 
the TMC-CONFIGURE request primitive 



NOTE 4: While on an assigned channel, or when active in a V+D advanced link or call, a full dual watching MS 
should still periodically receive the Direct Mode RF carrier if practicable, in order to look for calls 
addressed to itself. However, this may not always be practicable e.g. for a three-slot or four-slot V+D call 
or for the transmitting party in a circuit mode V+D call if the BS has assigned monitoring pattern II2 (i.e. 
three monitoring patterns). 

While on an assigned channel, or when active in a V+D advanced link or call, an idle dual watching MS 
need not attempt to receive the Direct Mode RF carrier. 

If practicable (i.e. unless Direct Mode requirements take precedence), a dual watching MS shall temporarily revert to 
receiving the V+D channel in all TDMA frames if: 

• it has V+D signalling messages to send; or 

• it receives a TMA-SAP signalling message from the BS for any of its valid addresses or event labels, other 
than the predefined broadcast group address (all ones). 

NOTE 5: When the MS is in a Direct Mode call, it need not revert to receiving the V+D channel in all TDMA 
frames when it has V+D signalling messages to send or has received a signalling message from the BS 
(see EN 300 396-3 [22], clause 8.4.7.10). 

The MS shall return to the dual watch reception cycle when it is on the MCCH or a common SCCH and a time T.220 
has elapsed since: 

• the higher layers indicated no V+D activity using the TMC-CONFIGURE request primitive; or 

• it sent its last V+D signalling message; or 

• it last received a TMA-SAP signalling message from the BS for one of its valid addresses or event labels, other 
than the predefined broadcast group address (all ones), 

whichever is the most recent. During this time-out period, the MS shall continue to receive the downlink MCCH or 
common SCCH slot in all TDMA frames if practicable (i.e. unless Direct Mode requirements take precedence), for any 
further signalling from the BS. 

NOTE 6: The BS should be aware that it will not always be practicable for the MS to receive the V+D channel in 
all TDMA frames during the T.220 time-out period e.g. if the MS is currently in a Direct Mode call or if 
the MS user decides to initiate or receive a Direct Mode call. 

NOTE 7: The dual watch reception cycle applies only on the MCCH or a common SCCH, not on an assigned 
channel. 
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An MS ends dual watch mode via an exchange of MM messages with the BS. MM instructs the MAC via the 
MLE-INFO, TL-CONFIGURE and TMC -CONFIGURE request primitives and the "Dual watch energy economy 
group" set to "Stay alive" to return to receiving the common control channel during all TDMA frames. The MAC shall 
begin this immediately and so the "Dual watch start point" parameter shall have no meaning in this case. 

An MS in dual watch mode may request to change its energy economy group via an exchange of MM messages with 
the BS. From the perception of the MAC, this function is seen only as receiving an instruction from MM to "Stay alive" 
and then receiving another instruction to enter dual watch mode with the specified energy economy group. 

If the MS is in dual watch mode and the MAC receives an instruction from MM to enter dual watch mode with a 
specified energy economy group then it shall attempt to receive and decode the relevant slot on the main carrier if 
practicable (i.e. unless Direct Mode requirements take precedence), in all TDMA frames up until and including the 
frame and multiframe given by the new "Dual watch start point". It shall then use the reception cycle defined by the 
new "Dual watch energy economy group". 

NOTE 8: This case may occur if the BS changes the MS's dual watch energy economy group. 

The MS cannot operate in both normal energy economy mode and dual watch mode at one time. An MS in energy 
economy mode may request to change to dual watch mode via an exchange of MM messages with the BS. Conversely, 
an MS in dual watch mode may request to change to energy economy mode via an exchange of MM messages with the 
BS. From the perception of the MAC, this function is seen only as receiving an instruction from MM to "Stay alive" and 
then receiving another instruction to enter the other mode with the specified energy economy group. 

The MS shall end dual watch mode if it leaves the RA. 

23.8 PDU transfer for traffic (TMD-SAP) 

Circuit mode traffic transmission applies only on 7i/4-DQPSK channels. 

23.8.1 Introduction 

For a message trunked system, a complete circuit mode call generally takes place on one 7i/4-DQPSK assigned channel. 
Before any traffic transmission, the BS allocates a traffic usage marker for the call. 

For a transmission trunked system, each traffic transmission (i.e. "over") takes place on a 7i/4-DQPSK assigned channel. 
Between "overs", the MS is directed to a common control channel or to an assigned SCCH. Before each traffic 
transmission, the BS allocates a traffic usage marker for use on the assigned channel. 

For a quasi-transmission trunked system, each traffic transmission takes place on a 3i/4-DQPSK assigned channel. At 
the end of an "over", the MS(s) remain on the assigned channel for a short period (i.e. the channel hang-time). If another 
traffic transmission for the call is requested within the hang-time then the same channel is used for that traffic 
transmission. Otherwise, after the hang-time, the BS directs the MS(s) to a common control channel, or to an assigned 
SCCH, until the next traffic transmission is requested; the BS then assigns a channel for that traffic transmission (either 
the previous assigned channel or a different channel). Before any traffic transmission on an assigned channel, the BS 
allocates a traffic usage marker for use on that channel. 

The choice between these modes is made by the BS. The MS procedures operate independently of this BS choice. 

During a call, ACCH is always available in frame 18. When frames 1 to 17 are not being used for traffic, the fast ACCH 
is available in frames 1 to 18 (see clause 23.3.1.3). In the case of independent allocation of uplink and downlink, or for 
an inter-site call, the availability of FACCH at any time may be independent on uplink and downlink. 

The usage of both upHnk and downlink is indicated, independently, in the ACCESS-ASSIGN PDU on the AACH. A 
traffic usage marker is used when the corresponding direction is in use for traffic (i.e. TCH or STCH). During FACCH, 
the uplink is controlled by the access field, and the downlink is marked with the assigned control or common control 
pre-set usage marker as appropriate. 

In traffic mode, on frames 1 to 17, capacity may be stolen from the circuit for signalling purposes, without changing the 
current mode of operation. Use of normal training sequence 2 (i.e. SF = 1) indicates when stealing has occurred and the 
MAC header in the first half slot indicates whether the second half slot is also stolen. This mechanism applies to both 
uplink and downlink. 
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See clause 19 for the configuration of the lower MAC in signalling and traffic mode. The default mode is signalling 
mode. 

NOTE: The STCH mechanism applies only when the channel is in traffic mode, allowing signalling messages to 
be sent within an "over", and without waiting for frame 18. For example: U-plane signalling 
(i.e. user-to-user signalling and/or encryption synchronization) is sent on STCH; Call Control (CC) PDU 
U-TX CEASED should normally be sent on STCH; and D-TX CEASED may be sent on STCH. C-plane 
signalling messages unrelated to the call may also be sent on STCH. 

Between "overs" on a message trunked (or quasi-transmission) trunked system, the assigned channel will 
normally return to signalling mode (FACCH). The SCH procedures then apply. 

23.8.2 Criteria for transmission and reception of traffic 

During a circuit mode call: 

• a sending MS needs to be instructed when to start sending traffic (and when to stop); 

• a receiving MS needs to know when to process any received TCH (and when to stop). 

This process shall be performed by CC messages sent by the BS to the appropriate MS(s). The CMCE in the MS shall 
then instruct the MS -MAC using the TMC-CONFIGURE request primitive. There are also some back-up mechanisms 
using the ACCESS-ASSIGN PDU. 

23.8.2.1 Use of TMC-CONFIGURE primitive 

For the purposes of the protocol description, it is assumed that the instruction from the CMCE for changing the 
operating mode in the MS-MAC comprises the following sub-parameters: 

switch U-plane on/off; 

Tx-grant flag; 

simplex/duplex flag; 

type of circuit (i.e. TCH/S, TCH/2,4, TCH/4,8, TCH/7,2); 

interleaving depth N; 

end-to-end encryption flag; 

user device; 

endpoint identifier. 

The possible combinations of the first three sub-parameters may be: 

a) Switch U-plane on, Tx-grant, Simplex: MS is authorized to transmit TCH; 

b) Switch U-plane on. Not Tx-grant, Simplex: MS is authorized to receive TCH; 

c) Switch U-plane on, Tx-grant, Duplex: MS is authorized to transmit and receive TCH; 

d) Switch U-plane off: Withdraws previous authorization to transmit 

and/or receive TCH. 

The upper MAC shall inform the lower MAC of the appropriate type of TCH logical channel for transmission and/or 
reception, since this affects the coding/decoding method. 

For the purposes of the protocol description, it is assumed that the process of the MAC issuing a TMA-UNITDATA 
indication primitive containing a CC message and then receiving the corresponding TMC-CONFIGURE request 
primitive is effectively instantaneous except in the case when the MS decides to obey a group addressed channel 
allocation after a delay. 
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If the MS decides to obey a group addressed channel allocation after a delay then the CMCE may indicate TCH receive 
authorization when it accepts the channel allocation. However, the MS-MAC shall not use this authorization if the 
decision to move to the allocated channel has been delayed by more than a time T.215 (see clause 23.8.2.2). If the 
decision has been delayed by more than a time T.215 then, after moving to the allocated channel, the MS shall not 
process received TCH until the "N.213 permission method" criterion applies (see clause 23.8.2.3.2) or until 
authorization by another CC message. 

NOTE 1: In case a) above, the MS continues to receive the downlink in the normal manner (subject to the defined 
monitoring pattern(s)) and using the procedures in clause 23.5.6.3 for interpretation of the downlink. The 
downlink may be either in signalling or traffic mode. 

NOTE 2: If the MS has independent circuit mode calls in progress on the uplink and downlink of the channel, it 
should use appropriate means to distinguish between the operating mode instructions from the CMCE. 

NOTE 3: The MAC may receive changes to the operating mode for the same call, with consecutive changes both 
containing the instruction to "Switch U-plane on". For example, this may occur if the next traffic 
transmission has already been requested so that there is no need to return to signalling mode. The most 
recent instruction for the call over-writes previous instructions, e.g. case b) after case a) withdraws the 
TCH transmit authorization and gives TCH receive authorization; case a) after case b) withdraws the 
TCH receive authorization and gives TCH transmit authorization. 

23.8.2.2 Timing of change of mode 

For a switch to U-plane transmission, the MS shall use the following timings: 

• If the downlink slot containing the transmit permission (or the final fragment) contained no channel change 
and no slot grant, then: 

if in frames 1 to 17, the MS shall start sending traffic in the corresponding uplink slot in that TDMA 
frame; 

if in frame 18, the MS shall start sending traffic in frame 1. 

NOTE 1 : If the MS with transmit permission has received previous slot grants on the assigned channel then that 
MS should assume that any granted slots in frames 1 to 17 are withdrawn whereas any granted slots in 
frame 18 are still valid. 

• If the downlink slot containing the transmit permission (or the final fragment) contained a slot grant, either 
with no channel change or with a grant on the allocated channel, then the MS shall start sending traffic in the 
next full uplink slot on the assigned channel in frames 1 to 17, following the end of the grant. This rule applies 
even if the grant exceeds the MS's requirement to send signalling messages. When the MS starts sending 
traffic, note 1 applies to any previous slot grants on the assigned channel. 

• If the downlink slot containing the transmit permission (or the final fragment) contained a channel change and 
no slot grant on the allocated channel, then: 

if CLCH(-Q) permission is given then the MS shall start sending traffic in the next uplink slot on the 
assigned channel in frames 1 to 17; this is the next valid full uplink traffic slot following the slot 
containing the potential CLCH subslot, even if the MS does not need to use CLCH; 

if CLCH(-Q) permission is not given, e.g. no change of RF carrier, then the MS shall start sending traffic 
in the first uplink slot on the allocated channel (as defined in clause 23.5.4.3.1) if that slot is in frames 
1 to 17, or else in frame 1. 

In the first traffic slot, and if the DATA-IN-BUFFER signal from the LLC indicates that there is a message in the buffer 
for this channel with the stealing permission parameter set to "steal within time T.214" or "steal immediately", then the 
MS-MAC shall issue a MAC-READY signal to the LLC offering stolen capacity, e.g. for a layer 2 acknowledgement to 
the layer 3 transmit permission message. 

NOTE 2: For the purposes of the above procedures for timing a switch to U-plane transmission, a "slot grant" refers 
to a grant with "granting delay" t- 1 1 1 12. So the MS should regard a "basic slot granting" element with 
"granting delay" = 1 1 1 12 as not being a slot grant. 
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For a switch to U-plane reception, with no channel change: 

• for a single-slot channel, or for a multi-slot channel in which the next downlink slot is not part of that channel, 
the MS shall switch to U-plane reception at the end of the downlink slot containing the receive permission; 

• for a multi-slot channel, and if the next downlink slot is part of that channel, the MS shall delay the switch to 
U-plane reception by one timeslot duration. 

EXAMPLE 1 : For a multi-slot channel comprising timeslots 2, 3 and 4, with a switch instruction in downlink 
slot 2, the MS assumes SCH for downlink slot 3 and then switches to U-plane reception for 
downlink slot 4. Whereas, if the switch instruction is in downlink slot 4 then the MS switches to 
U-plane reception for downlink slot 2 in the next TDM A frame. 

For a switch to U-plane reception, with a channel change, the MS shall switch to U-plane mode when it moves to the 
allocated channel, for reception of the first downlink slot on the allocated channel (as defined in clause 23.5.4.3.1). The 
MS shall use this procedure for an individually addressed channel allocation or if the MS makes an immediate decision 
to obey a group addressed channel allocation. Also, the MS may use this procedure when it decides to obey a group 
addressed channel allocation after a delay, provided that the MS-MAC receives the TMC-CONFIGURE request 
primitive accepting the channel allocation within a time T.215 after receipt of the channel allocation. 

In the case of a group addressed channel allocation, if the MS-MAC receives the TMC-CONFIGURE request primitive 
accepting the channel allocation more than a time T.215 after receipt of the channel allocation then, after moving to the 
allocated channel, the MS shall not process received traffic until the "N.213 permission method" criterion applies (see 
clause 23.8.2.3.2) or until authorization by another CC message. 

For a switch out of U-plane transmission: 

• for a single-slot channel, or for a multi-slot channel in which the next uplink slot is not part of that channel, the 
MS shall switch mode immediately, i.e. as soon as the downlink message has been processed; 

• for a multi-slot channel, and if the next uplink slot is part of that channel, the MS shall delay the switch by one 
timeslot duration. 

EXAMPLE 2: For a multi-slot channel comprising timeslots 2, 3 and 4, with a switch instruction in downlink 
slot 3, e.g. in frame 10, the MS continues to transmit TCH or STCH in uplink slot 2 before 
switching. Whereas, if the switch instruction is in downlink slot 2 then the MS stops U-plane 
transmission at the end of the coinciding uplink slot 4. 

For a switch out of U-plane reception: 

• for a single-slot channel, or for a multi-slot channel in which the next downlink slot is not part of that channel, 
the MS shall switch mode at the end of the downlink slot containing the switch instruction; 

• for a multi-slot channel, and if the next downlink slot is part of that channel, the MS shall delay the switch by 
one timeslot duration. 

EXAMPLE 3: For a multi-slot channel comprising timeslots 2, 3 and 4, with a switch instruction in downlink 
slot 2, the MS assumes TCH or STCH for downlink slot 3 and SCH for downlink slot 4. 

NOTE 3: If the BS does not receive an expected layer 2 acknowledgement to a downlink message giving or 

withdrawing authorization to receive traffic on the downlink, it cannot know whether the MS actually 
received the message; therefore, it cannot know whether the MS is in signalling or traffic mode for 
reception. In either case, if the BS wishes to send a re-transmission, it is necessary that the MS is able to 
interpret the downlink channel correctly. At this time, it is recommended that the BS uses only normal 
training sequence 2, sending either STCH + STCH or SCH/HD + SCH/HD. Interpretation of these forms 
by MSs is very similar, provided that the BS uses only "length indication" 1111102or llllll2in the last 
PDU in a first half slot, even if that half slot actually contains SCH/HD. 

NOTE 4: After being authorized to receive traffic, the MS may switch to traffic mode almost immediately. If TCH 
from the source is not ready at this time, the BS should send C-plane STCH + STCH on the downlink, 
e.g. containing Null PDUs. 
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NOTE 5: As specified above, the switch out of U-plane mode is almost immediate after the CMCE has received the 
command from the BS. Therefore, for a circuit mode data call with an interleaving depth of N = 4 or 8, 
the CMCE in the transmitting MS should ensure that the MS has been able to issue N - 1 slots containing 
tail bits (zeros) to the lower MAC at the end of the required data transmission (on each allocated slot in 
the case of a multi-slot channel) before sending the U-TX CEASED PDU to the BS. These tail bits are 
needed to complete the interleaving of the circuit mode data. 

23.8.2.3 AACH mechanisms 

The following procedures specify criteria for stopping transmitting or receiving traffic. There are also criteria for 
leaving an assigned traffic channel, based on received ACCESS-ASSIGN PDUs. (See clause 23.5.6 for maintenance of 
an assigned channel.) 

23.8.2.3.1 MS transmitting traffic 

The MS shall not transmit traffic unless it has been authorized by a CC message and has a traffic usage marker 
applicable to the uplink channel (i.e. assigned with element "Up/downlink assigned" or "Up/downlink assigned for 
augmented channel allocation" = IO2 or 1 12). 

During traffic transmission, the MS shall receive and attempt to decode the downlink assigned channel for at least those 
frames defined by the monitoring pattern information, within the capabilities of that MS. 

After starting to transmit traffic, and if the BS does not allow U-plane DTX (i.e. discontinuous traffic transmission by 
the MS), then the MS shall transmit traffic (TCH and/or STCH) in frames 1 to 17, in successive slots on the uplink 
assigned channel, as defined by element "Timeslot Assigned", until any one of the following criteria a), b), c) or d) 
occurs. 

NOTE 1 : The "U-plane DTX" element in the SYNC PDU indicates whether or not the BS supports discontinuous 
traffic transmission by the MS. 

After starting to transmit traffic, and if the BS allows U-plane DTX, then the MS may transmit traffic (TCH and/or 
STCH) in frames 1 to 17 on the uplink assigned channel, and shall transmit in at least one traffic slot every T.213 
TDMA frames, until any one of the following criteria a), b), c) or d) occurs. 

a) Authorization to transmit traffic is withdrawn (either by an instruction to switch the U-plane off or by a switch 
from transmit to receive for this call). 

b) If one or more monitoring patterns were assigned, i.e. element "Monitoring Pattern" t- OO2: 

N.21 1 successive ACCESS-ASSIGN PDUs received in frames 1 to 17 on the downlink assigned channel 
contain "Header" t- 11 2 or do not contain the correct uplink traffic usage marker. 

If no monitoring pattern was assigned, i.e. element "Monitoring Pattern" = OO2: 

N.21 1 successive ACCESS-ASSIGN PDUs received in any TDMA frame on the downlink assigned 
channel contain "Header" t- 1 12 or do not contain the correct uplink traffic usage marker. 

c) If one or more monitoring patterns were assigned, i.e. element "Monitoring Pattern" t- OO2: 

a time T.21 1 elapses without receipt of an ACCESS-ASSIGN PDU in frames 1 to 17 on the downlink 
assigned channel, containing "Header" = 1 12 and containing the correct uplink traffic usage marker. 

If no monitoring pattern was assigned, i.e. element "Monitoring Pattern" = OO2: 

a time 18 x T.21 1 elapses without receipt of an ACCESS-ASSIGN PDU in any TDMA frame on the 
downlink assigned channel, containing "Header" = 1 12 and containing the correct uplink traffic usage 
marker (as "Field 2" in frames 1 to 17 or "Field 1" in frame 18). 

d) The MS leaves the assigned channel (see clause 23.5.6. 1). 

NOTE 2: For a multi-slot channel, if the MS is not frequency full duplex, and if the BS assigns monitoring 

pattern(s) that the MS is not capable of following in any slots in frames 2 to 17, then, in criteria b) and c), 
the MS should use the method specified for element "Monitoring Pattern" = OO2. 
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In all cases a), b), c) and d), the MS shall stop transmitting traffic (TCH and STCH) and shall revert to the normal 
C-plane methods of random access and reserved access in all frames 1 to 18. 

In cases b) or c), the MS -MAC shall report the change of mode to the higher layers using the TMC-REPORT indication 
primitive. 

In case d), the interruption may be only temporary. If the MS is changing channel on instruction from the BS and if: 

the "Allocation Type" = OO2 or 1 12 ("Replace" or "Replace + CSS channel"); and 

the MS is being directed to an assigned channel (i.e. element "Timeslot Assigned" -^ OOOO2); and 

the uplink is assigned (i.e. element "Up/downlink assigned" or "Up/downlink assigned for augmented channel 
allocation" = IO2 or II2); and 

the MS receives a traffic usage marker assignment with the channel allocation; and 

the MS does not receive a CC message withdrawing authorization to transmit traffic; and 

this is an individually addressed channel allocation or, for a group addressed channel allocation, the MS 
decides within a time T.216 to obey the channel allocation, 

then, on receipt of the channel allocation, the MS-MAC shall stop transmitting traffic on the current channel. For a 
single-slot channel, or for a multi-slot channel in which the next uplink slot is not part of that channel, the MS shall stop 
transmitting traffic immediately. For a multi-slot channel, and if the next uplink slot is part of that channel, the MS shall 
delay the switch by one timeslot duration. After changing channel, the MS shall continue traffic transmission as 
follows: 

if the MS has a slot grant on the assigned channel 

then the MS shall continue traffic transmission in the next uplink slot on the 
assigned channel {in frames 1 to 17) , following the end of the slot grant 
else 
if "Immediate CLCH{Q) permission" is given 

then the MS shall continue traffic transmission in the next full uplink slot on the 

assigned channel {in frames 1 to 17) , following the slot containing the potential 
CLCH subslot 
else the MS shall continue traffic transmission in the first uplink slot on the 
allocated channel (as defined in clause 23.5.4.3.1) if that slot is in 
frames 1 to 17 or otherwise in frame 1. 

This rule shall apply both for allocation within the same cell and for a different cell (seamless handover). 

For a channel change that does not conform to the above, or if the MS decides not to move to the allocated channel, the 
MS -MAC shall stop transmitting traffic and shall report the change of mode to the higher layers. 

If, after starting to transmit traffic and at any time other than during a temporary interruption for channel change, the 
MS receives a slot grant addressed to itself, and granting a reserved uplink subslot or slot(s) in frames 1 to 17 (i.e. 
where it expected to transmit traffic), then the MS-MAC shall stop transmitting traffic, reporting the change of mode to 
the higher layers. 

NOTE 3: The scenario above should not occur except in case of transmission errors. It is not intended for use by the 
BS as a normal method for ending U-plane transmission. 

NOTE 4: Criterion b) refers to a check on those ACCESS-ASSIGN PDUs that are received by the MS, irrespective 
of whether or not these are in successive slots on the assigned channel. Then criterion c) covers the case 
when the ACCESS-ASSIGN PDU is not received during the specified time. 

If no monitoring pattern is assigned, the BS should use "Header" 1 12 in ACCESS-ASSIGN PDUs in 
frame 18 on the downlink assigned channel, including the traffic usage marker of the transmitting MS. 
This applies also for a multi-slot channel if the BS assigns monitoring pattern(s) that the MS may not be 
capable of following in any slots in frames 2 to 17. 
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NOTE 5: The "channel replace" mechanism without withdrawal of transmit authorization may be used within the 
cell, for convenience of BS resource allocation, or between cells e.g. for seamless handover. Before 
continuing U-plane transmission, the MS may be required to transmit a C-plane reply, in a reserved slot 
on either the current or allocated channel, or by stealing. 

Alternatively, the BS may prefer to interrupt the traffic transmission by sending the CC PDU 
D-TX WAIT (temporarily withdrawing transmit permission). 

23.8.2.3.2 MS receiving traffic 

The MS should process received traffic after authorization by a CC message, except that it shall not process received 
TCH if it does not have a traffic usage marker applicable to the downlink channel (i.e. assigned with element 
"Up/downlink Assigned" or "Up/downlink assigned for augmented channel allocation" = OI2 or 1 12). Also, if a group 

addressed channel allocation was sent with the CC message and the decision to accept the channel allocation was 
delayed by more than time T.215 then the MS shall not process received TCH on the allocated channel until the "N.213 
permission method" criterion applies or until authorization by another CC message. 

The MS may process received traffic, without specific authorization, if N.213 ACCESS-ASSIGN PDUs received in 
frames 1 to 17 in successive slots appropriate to the downlink assigned channel contain Header t- OO2 and contain the 
correct downlink traffic usage marker for this MS. The MS-MAC should report the change of mode to the higher layers 
using the TMC-REPORT indication primitive. 

NOTE 1: If the CMCE indicates traffic receive permission when it accepts a group addressed channel allocation 
after a delay of more than time T.215 then the MS-MAC is not precluded from reducing its value of 
N.213 provided that the reduced value of N.213 > 2. This applies also for a channel replacement without 
withdrawal of receive authorization if the MS accepts a group addressed channel allocation after a delay 
of more than time T.215 (see below). The reduced value of N.213 may apply until the MS next receives a 
CC message indicating authorization or withdrawal of authorization to transmit or receive traffic on the 
allocated channel. 

The MS shall process any received traffic (TCH and STCH) in frames 1 to 17 in slots on the downlink assigned channel 
until any one of the following occurs: 

a) authorization to receive traffic is withdrawn (either by an instruction to switch the U-plane off or by a switch 
from receive to transmit for this call); 

b) N.212 successive ACCESS-ASSIGN PDUs received in frames 1 to 17 on the downlink assigned channel 
contain "Header" = OO2 or do not contain the correct downlink traffic usage marker; 

c) a time T.212 elapses without receipt of an ACCESS-ASSIGN PDU in frames 1 to 17 on the downlink assigned 
channel, containing "Header" t- OO2 and containing the correct downlink traffic usage marker; 

d) the MS leaves the assigned channel (see clause 23.5.6.1), unless the criteria described below are satisfied. 

In all cases, the MS shall stop processing received traffic. 

In cases b), c) or d), the MS-MAC shall report the change of mode to the higher layers using the TMC-REPORT 
indication primitive. 

In all cases, the MS may again process received traffic either after authorization by a CC message or by using the 
"N.213 permission method" described above. 

The exception to case d) is that, if the MS changes channel on instruction from the BS and if: 

the "Allocation Type" = OO2 or 1 12 ("Replace" or "Replace H- CSS channel"); and 

the MS is being directed to an assigned channel (i.e. element "Timeslot Assigned" t- OOOO2); and 

the downlink is assigned (i.e. element "Up/downlink Assigned" or "Up/downlink assigned for augmented 
channel allocation" = OI2 or II2); and 

the MS receives a traffic usage marker assignment with the channel allocation; and 

the MS does not receive a CC message withdrawing authorization to receive traffic; and 
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• this is an individually addressed channel allocation or, for a group addressed channel allocation, the MS 
decides within a time T.215 to obey the channel allocation, 

then the MS -MAC shall switch out of U-plane reception at the end of the downlink slot containing the channel 
allocation; or, for a multi-slot channel, and if the next downlink slot is part of that channel and the MS is still on the 
current channel to receive that slot (see note 2), the MS shall delay the switch by one timeslot duration. The MS shall 
switch back to U-plane reception when it moves to the allocated channel, using the newly assigned usage marker, for 
reception of the first downlink slot on the allocated channel (as defined in clause 23.5.4.3.1). 

This rule shall apply both for allocation within the same cell and for a different cell. 

NOTE 2: For the purposes of this procedure it is assumed that, for a multi-slot channel, and if the next downlink 
slot is part of that channel, then the MS is "still on the current channel to receive that slot" only in the 
cases defined in condition b) of procedure 1) in clause 23.5.4.3.1 and, for a frequency full duplex MS, 
condition c) of procedure 1) in clause 23.5.4.3.1 i.e. in the cases of a channel allocation with a slot grant 
on the current channel and, for a frequency full duplex MS, if the next immediate uplink slot following 
the channel allocation is part of the current channel and the MS is transmitting traffic in that slot or was 
previously granted that slot (or a subslot in that slot) for reserved access. So, for the purposes of this 
procedure, it is assumed that the MS is not "still on the current channel to receive that slot" if the timing 
of the channel change is based on condition a) of procedure 1) in clause 23.5.4.3.1. 

NOTE 3: Criterion b) refers to a check on those ACCESS-ASSIGN PDUs that are received by the MS, irrespective 
of whether these are in successive slots on the assigned channel. Whereas the "N.213 permission method" 
applies only if ACCESS-ASSIGN PDUs are received in successive traffic slots on the assigned channel. 

NOTE 4: The permission method based on parameter N.213 should not be used by an MS that is transmitting in 
simplex mode and that has only one circuit mode call on this channel i.e. the MS should not attempt to 
transmit and receive simultaneously in a simplex call. 

NOTE 5: The "channel replace" mechanism without withdrawal of receive authorization may be used within the 
cell, for convenience of BS resource allocation, or between cells e.g. for seamless handover. 

If an MS that is receiving traffic is sent to a different timeslot during an end-to-end encrypted call, the BS 
may choose to interrupt the transmitting station with the D-TX WAIT PDU, thereby causing the 
transmitting station to re-send encryption synchronization when the transmission starts again. 

NOTE 6: In the case of circuit mode data, in order to avoid corrupting downlink data transmission, the BS designer 
may prefer (when possible) to send any channel allocation commands or D-TX WAIT PDUs in frame 18. 

NOTE 7: The MS is not permitted to maintain traffic receive authorization if it accepts a group addressed channel 
allocation after a delay of more than time T.215; after moving to the new channel, it cannot process 
received TCH until the "N.213 permission method" criterion applies (using the traffic usage marker for 
the new channel) or until authorization by a CC message. 



23.8.2.3.3 



Multi-slot interleaving with interruption 



If a circuit mode data transmission is interrupted, either by use of the CMCE's D-TX WAIT mechanism or by a 
"channel replace", as defined in the above two clauses, then the MS shall continue with the transmission or reception of 
the data as if the intervening time out of U-plane mode had not been present. This rule includes the 
interleaving/de-interleaving of the data for interleaving depth N = 4 or 8. 

For a single-slot channel with N = 4 or 8, the MS shall continue to process the U-plane data after the interruption, 
performing interleaving/de-interleaving of the old data with the new data as traffic blocks are transmitted/received. 

For a multi-slot channel with N = 4 or 8, multiple single-slot data TCHs are operated in parallel in order to obtain the 
multi-slot TCH transmission, as defined in clause 23.3.5. After an interruption, the order of presentation of the data at 
the receiving side shall be maintained. Therefore, across the interruption, the single-slot TCHs may be linked between 
different timeslot numbers according to the next occurring traffic slot. 
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EXAMPLE: For a multi-slot channel comprising timeslots 1, 2 and 3, where a slot 1 is the last traffic slot 
before interruption and a slot 3 is the next traffic slot: 

the old interleaving process corresponding to slot 2 continues in slot 3; 

the old interleaving process corresponding to slot 3 continues in slot 1 ; 

the old interleaving process corresponding to slot 1 continues in slot 2. 

Similarly, for a multi-slot channel comprising timeslots 1, 2 and 3, with a new channel allocation 
comprising timeslots 1, 3 and 4, where a slot 2 contained the last traffic on the old channel and a 
slot 3 contains the first traffic on the new channel: 

the old interleaving process corresponding to slot 3 continues in slot 3; 

the old interleaving process corresponding to slot 1 continues in slot 4; 

the old interleaving process corresponding to slot 2 continues in slot 1 . 

This second example could be caused either by use of the channel replace without withdrawal of 
U-plane authorization, or by use of the D-TX WAIT mechanism with a channel replacement 
during the pause. 

NOTE: The procedures defined in this clause do not apply for a group addressed channel replacement if the MS 
decides to obey the channel allocation after a delay. 

23.8.3 Exchange of information at tine TMD-SAP 

In the protocol model, the actual user traffic is transferred between the U-plane application (e.g. the speech CODEC) 
and the MS-MAC via the TMD-SAP. The TMD-SAP is used for the transfer of speech frames or circuit mode data. It is 
also used if the U-plane application steals from the traffic capacity to send U-plane signalling. 

For the purposes of the protocol description, the following services primitives are used. However, this does not imply 
any specific implementation. The word "shall" is used with the primitives and their parameters for traceability reasons 
in the protocol model, but the primitives are not testable. 

• The TMD-UNITDATA request primitive shall be used when the U-plane application wishes to send 
information to the peer entity. 

• The TMD-UNITDATA indication primitive shall be used for the MS -MAC to deliver information from the 
peer entity. 

• The TMD-REPORT indication primitive shall be used by the sending MAC to issue reports to the U-plane 
application e.g. at the start and stop of traffic transmission, and when the MS changes channel within an 
"over", and when the MAC has stolen from the traffic capacity. It shall also be used by the receiving MAC at 
the start of a call. 

The parameters specific to the TMD-UNITDATA primitive are as follows (see clause 20): 

a) Half slot content: 

The unit of information in the TMD-UNITDATA primitive is one half slot. The U-plane application shall 
provide a TM-SDU of the correct size for the appropriate logical channel, so that the MS -MAC does not have 
to insert filler bits to complete the MAC block nor have to remove filler bits on reception. 

In particular, when the U-plane application steals from the traffic capacity for U-plane signalling, the 
TM-SDU shall always be 121 bits. The upper MAC shall then add a 3-bit MAC header, making the MAC 
block up to the 124 bits required for STCH. The U-plane signalling may be for user-to-user signalling or for 
encryption synchronization. However, the MAC is not aware of the intended purpose of the U-plane 
signalling. (Any necessary discrimination shall be included within the TM-SDU.) 

User traffic TCH does not have a MAC header. 
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b) Half slot position: 



Each transferred half slot (in either direction) should be accompanied by a marker identifying it as the first or 
second half slot of a timeslot. 

At all points in the system, half slots should be grouped in pairs, equivalent to the data transmitted over the air 
interface in one slot. The binding between these pairs shall remain intact and the correct timing/ordering 
relationships with adjacent half slots preserved, even when a half slot is stolen and the half slots are processed 
separately by the MAC. 

c) Stolen indication: 

At the transmitting side, this parameter shall indicate whether the half slot is stolen for U-plane signalling or 
not stolen. 

At the receiving side, this parameter shall indicate whether the half slot was stolen for C-plane signalling, 
stolen for U-plane signalling or not stolen. 

d) Half slot importance: 

This parameter may be used only in the TMD-UNITDATA request primitive. It indicates the importance of 
the U-plane information, enabling the sending MS-MAC to decide when and whether to steal from the traffic 
capacity and to decide whether to use U-plane DTX (discontinuous traffic transmission). Four levels of 
importance may be used: no importance, and low, medium and high importance. 

e) Half slot condition: 

This parameter may be used only in the TMD-UNITDATA indication primitive. It indicates to the receiving 
U-plane application whether a half traffic slot was received successfully. It may take the following values: 

"Good" if the half slot was decodeable; 

"Bad" if a valid training sequence was detected but the CRC check failed; 

"Null" if no valid training sequence was detected. 

The distinction between "Good" and "Bad" is not appropriate for TCH/7,2. 

f) User device: 

The user device parameter shall identify the appropriate circuit. 

NOTE 1 : For the purposes of the protocol description, channel encoding and decoding are performed in the lower 
MAC. However, this does not imply any particular implementation. If, for example, the implementers 
were to choose to perform the channel coding of TCH directly in the CODEC, then the descriptions of 
half slot transfer generally still apply (though the distinction between "Good" and "Bad" in the "half slot 
condition" parameter is no longer relevant). 

NOTE 2: For the purposes of the protocol description, the unit of exchange at the TMD-S AP is always a half slot 
(corresponding to one speech frame). However, this does not imply any particular implementation. For 
example, implementers may prefer to use a full slot of data as the unit of exchange for circuit mode data 
TCH. 

NOTE 3: It is assumed that the U-plane application provides valid data in the "half slot content" parameter even if 
the "half slot importance" is set to "no importance". 

23.8.3.1 Interface at transmitting IVIS 

At the start of a call (or before each "over"), or if the basic service information changes, the MS-MAC shall issue a 
report to the U-plane application to supply the traffic type, the interleaving depth, the number of slots per TDMA frame, 
a flag indicating whether end-to-end encryption applies and the user device parameter. 
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When the MS has been authorized to transmit TCH, and has estabhshed whether it will steal the first half slot for 
C-plane signalling (e.g. a layer 2 acknowledgement), the MS-MAC shall issue a report to the U-plane application. This 
report shall indicate the initial half slot synchronization i.e. whether the first valid U-plane half slot is a first or second 
half slot; that half slot may then be used either for TCH or for U-plane signalling. 

A report should be issued to the U-plane application if there is any interruption (e.g. a channel change) so that, for an 
end-to-end encrypted call, the U-plane application can send encryption synchronization again. 

A report should also be issued to the U-plane application when traffic transmission is no longer permitted. 

When transmitting a slot in traffic mode, the sending MS-MAC is generally given the first half slot by the U-plane 
application, in a TMD-UNITDATA request primitive. That half slot may be either TCH, or U-plane signalling in the 
case of stealing by the U-plane application. 

If the MS-MAC decides to steal the first half slot for C-plane signalUng then the MAC should issue a TMD-REPORT 
indication primitive, enabling the U-plane application to revise the intended use of the second half slot. 

The MS-MAC is then given the second half slot in another TMD-UNITDATA request primitive. Again, if the 

MS -MAC decides to steal the half slot for C-plane signalhng then the MAC should issue a TMD-REPORT indication 

primitive. 

In the case of circuit mode data with low or high protection: if the U-plane application steals the first half slot but not 
the second half slot then it should issue two TMD-UNITDATA request primitives for the first half slot (one containing 
the U-plane signalling data and the other containing TCH) and one TMD-UNITDATA request primitive for the second 
half slot (containing TCH). In the case of circuit mode data with interleaving depth N = 4 or 8: if the U-plane 
application steals both half slots then it should issue two TMD-UNITDATA request primitives for each half slot (one 
containing the U-plane signalling data and the other containing TCH). 

At this time, the MS-MAC has the contents of one slot. Permitted combinations for the two half slots are as follows: 

a) Not stolen i.e. TCH / Not stolen i.e. TCH; 

b) Stolen for C-plane / Not stolen i.e. TCH 

c) Stolen for U-plane / Not stolen i.e. TCH 

d) Stolen for C-plane / Stolen for C-plane; 

e) Stolen for C-plane / Stolen for U-plane; 

f) Stolen for U-plane / Stolen for C-plane; 

g) Stolen for U-plane / Stolen for U-plane. 

In case a), and if the BS allows U-plane DTX, the MS may decide not to transmit in the slot, based on the "half slot 
importance" of the two half slots. If the MS transmits in the slot then normal training sequence 1 shall be used, with a 
full slot of TCH (MAC -TRAFFIC PDU). In all the other cases, normal training sequence 2 shall be used and the 
stealing procedure described in clause 23.8.4 shall apply. 

In cases b) and c), for a speech call or unprotected data, the upper MAC shall issue a half slot of STCH and a half slot 
of TCH to the lower MAC. In cases d), e), f) and g), for a speech call or unprotected data, the upper MAC shall issue 
two half slots of STCH to the lower MAC. 

In cases b) and c), for a circuit mode data call with low or high protection, the upper MAC shall issue both a half slot of 
STCH and a full slot of TCH to the lower MAC. In cases d), e), f) and g), for a circuit mode data call with N = 1, the 
upper MAC shall issue two half slots of STCH to the lower MAC. In cases d), e), f) and g), for a circuit mode data call 
with N = 4 or 8, the upper MAC shall issue two half slots of STCH and also a full slot of TCH to the lower MAC. 

NOTE 1: Not stolen + Stolen for C-plane is not a permitted combination. 

If the MAC receives Not stolen + Stolen for U-plane from the U-plane application, it could use case e), 
replacing the traffic with a dummy C-plane message (containing no TM-SDU). However, this would 
make inefficient use of the channel. It is recommended that the U-plane application does not request this 
form. 
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NOTE 2: In an implementation, it may be preferred that (when practicable) the MAC informs the U-plane 

application as soon as it knows that it will perform C-plane stealing. For example, for a high priority 
C-plane message, the MAC may intend to steal irrespective of the U-plane half slot importance. 

NOTE 3: The above procedure specifies that, for protected circuit mode data with stealing in a slot, the upper MAC 
may issue both the STCH and a full slot of TCH to the lower MAC. This is because, for protected circuit 
mode data, the lower MAC replaces traffic bits with STCH bits after normal coding and interleaving of 
the TCH (see clause 8). This contrasts with the method for speech, where the second half slot is half-slot 
interleaved if the first half slot is stolen. 

23.8.3.2 Interface at receiving MS 

At the start of a call, or if the basic service information changes, the receiving MS-MAC shall issue a report to the 
U-plane application to supply the traffic type, the interleaving depth, the number of slots per TDMA frame, a flag 
indicating whether end-to-end encryption applies and the user device parameter. 

The following procedures in this clause shall apply for reception in frames 1 to 17 by an MS that is authorized to 
receive TCH. 

TCH shall be passed to the U-plane application. 

U-plane signalling shall be passed to the U-plane application after removal of the 3-bit MAC header. 

C-plane STCH shall be processed by the MAC, and any suitably addressed TM-SDUs shall be passed to the LLC. 

In all cases, for each half slot, the MS-MAC shall issue the TMD-UNITDATA indication primitive to the U-plane 
application containing any U-plane information (TCH or STCH) and indicating whether the half slot was stolen for 
C-plane signalling, stolen for U-plane signalling or not stolen. 

For protected circuit mode data, in the case of a slot in which only the first half slot was stolen, the upper MAC should 
receive a half slot of STCH and a full slot of TCH from the lower MAC. The upper MAC shall issue a 
TMD-UNITDATA indication primitive to the U-plane application containing the U-plane signalling data (if the first 
half slot was stolen for U-plane signalling) and shall issue two TMD-UNITDATA indication primitives containing 
TCH, one for each half slot. For circuit mode data with N = 4 or 8, in the case that both half slots are stolen, the upper 
MAC should receive two half slots of STCH and a full slot of TCH from the lower MAC. The upper MAC shall issue 
the appropriate TMD-UNITDATA indication primitive(s) to the U-plane application containing U-plane signalling data 
(if either half slot was stolen for U-plane signalling) and shall issue two TMD-UNITDATA indication primitives 
containing TCH. 

NOTE 1 : For the purposes of the protocol description, in the case of U-plane stealing from circuit mode data with 
N = 1 : when the U-plane signalling data is delivered to the U-plane application, it is associated with the 
same half slot as the circuit mode data delivered for that half slot. In any instances for which it is 
necessary to define the relative order of the two types of data associated with a half slot, it is 
recommended that the U-plane application considers the U-plane signalling data associated with the half 
slot to be available before the circuit mode data associated with that half slot. 

The same principle applies to circuit mode data with N = 4 or 8. However, the N - 1 traffic frame delay 
procedure for U-plane signalling also applies, as described below. 

For the purposes of the protocol description (see note 3): in the case of U-plane stealing from circuit mode data with 
N = 4 or 8, the receiving upper MAC shall delay the issuing of the TMD-UNITDATA indication primitive(s) containing 
the U-plane signalling data by N - 1 traffic frames. 

NOTE 2: This procedure for delaying the delivery of signalling data for N = 4 and 8 applies only to U-plane 
stealing (not to C-plane stealing). 

The procedure is defined so that the U-plane signalling is delivered to the U-plane application with the 
same U-plane circuit mode data as when it was given by the sending U-plane application to the sending 
upper MAC. The need for the procedure arises because the multi-slot interleaving causes the circuit mode 
data to be delayed by N - 1 traffic frames across a link of the air interface, whereas the U-plane signalling 
is not delayed. 
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NOTE 3: For the purposes of the protocol description, the U-plane signalling is delayed in the upper MAC. 

However, in an implementation, it may be preferred that the upper MAC delivers the U-plane signalling 
to the U-plane application as soon as it is received. In this case, it is a task of the U-plane application to 
delay position-sensitive signalling (such as end-to-end encryption synchronization) before use. 

In the case of un-decodeable TCH, the MS-MAC may pass the received data to the U-plane application, but shall set the 
"half slot condition" parameter appropriately in the TMD-UNITDATA indication primitive. 

23.8.4 Stealing from circuit mode capacity 
23.8.4.1 Uplink stealing 

23.8.4.1 .1 Transmission on uplink STCH 

Transmission on STCH shall only be used by an MS that has been authorized to transmit traffic. 
The appropriate PDUs for C-plane STCH on the uplink shall be: 

• MAC -DATA PDU: first or second half slot; 

• MAC-END PDU: second half slot only (final fragment). 
The appropriate PDU for U-plane STCH shall be: 

• MAC-U-SIGNAL PDU: first or second half slot. 

The MAC header of a MAC-U-SIGNAL PDU sent in a first half slot shall indicate whether the second half slot is also 
stolen, using the second half slot stolen flag. If the second half slot is stolen, it may contain either U-plane or C-plane 
signalling (as indicated by the first MAC header in the second half slot). 

For C-plane stealing within the first half slot, PDU association may be used. The "Length indication" in the last 
MAC-DATA PDU, or in the only MAC-DATA PDU, in the first half slot shall indicate whether the second half slot is 
also stolen. 

i) "Length indication" < OIOOOO2: second half slot not stolen. 

Then the second half slot shall contain TCH (MAC -TRAFFIC PDU). 

ii) "Length indication" = 1 1 1 1 IO2: second half slot stolen, no fragmentation. 

Then the second half slot may contain either U-plane or C-plane signalling (as indicated by the first MAC 
header in the second half slot). For C-plane signalling, PDU association may be used within the second half 
slot. 

iii) "Length indication" = IIIIII2: second half slot stolen, start of fragmentation. 

Then the final fragment shall be sent in the second half slot (except in case of cancellation), using the 

MAC -END PDU. If PDU association is used within the second half slot, then the fragment shall be sent as the 

first PDU in the MAC block. 

After transmitting a C-plane TM-SDU, the MS-MAC shall report to the LLC that the message has been sent by stealing 
(using the TMA-REPORT indication primitive). 

23.8.4.1 .2 Criteria for uplink stealing 

When an MS is authorized to transmit traffic, the MS -MAC may steal from the traffic capacity to send C-plane 
signalling. The MS then sends C-plane signalling instead of the data received from the U-plane application. The 
MS-MAC shall not move the replaced U-plane data (neither traffic nor signalling) to a different half slot or slot. 

The MS-MAC should report C-plane stealing to the U-plane application, enabling the application to revise the intended 
use of subsequent half slots, or to retransmit any U-plane signalling that has been overwritten by the MAC. 
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The following procedures shall apply for the different settings of the stealing permission parameter for the C-plane 

message. 

a) Steal immediately 

The MS-MAC shall send the C-plane message at the first opportunity on the uplink assigned channel, without 
regard to the half slot importance. This rule shall apply to both one- and two-half-slot messages. 

For this setting of the stealing permission parameter, and if the MS is authorized to transmit traffic, the 
MS-MAC shall use stealing in preference to using random access or reserved access on frame 18. 

b) Steal within time T.214 

If the MS has not been granted a reserved subslot or slot in frame 18 (i.e. in the uplink SACCH for this 
channel) then the MS-MAC shall send the message within the next T.214 traffic slots on the uplink assigned 
channel (i.e. within the next T.214 TDMA frames 1 to 17 for a single-slot channel). This rule shall apply to 
both one- and two-half-slot messages. 

The MS-MAC should send the message in the first slot for which the half slot importance is not "high". Or, if 
this does not occur within T.214 - 1 slots, the MS-MAC shall send the message in the T.214'th traffic slot on 
the uplink assigned channel, without regard to the half slot importance. 

c) Steal when convenient 

The MS designer should choose suitable criteria for deciding when the MS-MAC may steal, based on the 
priority of the C-plane message, the half slot importance and the time since the last stealing occurrence. It is 
recommended that the MS-MAC does not re-steal over U-plane signalling. 

d) Stealing not required 

The MS-MAC should not use stealing to send the message (unless the half slot importance of the traffic is set 
to "no importance"). 

The MS designer should note that frequent stealing would degrade the quality of the circuit. 

NOTE 1: The stealing permission parameter should be set to "steal immediately" for U-TX CEASED (and 

U-DISCONNECT if currently transmitting traffic). The stealing permission parameter should be set to 
"steal within time T.214" for the reply to a BS message received while the MS is transmitting traffic, 
e.g. for a layer 2 acknowledgement. 

NOTE 2: For "steal within time T.214", the MS-MAC may plan when to steal based on the stealing permission 
parameter in the DATA-IN-BUFFER signal from the LLC. The MAC should not issue the 
MAC -READY signal until it is actually ready to send the message, thereby allowing the maximum time if 
the layer 3 in the MS is preparing a response to the BS message. 

23.8.4.1 .3 Stealing repeats mechanism 

When the MS-MAC has used stealing to transmit a C-plane PDU with stealing permission parameter = "steal 
immediately", it shall check the setting of the "stealing repeats flag" in the TMA-UNITDATA request primitive. For a 
message with stealing permission parameter t- "steal immediately", or if this flag is not set, the MS-MAC shall regard 
the requested procedure as complete and shall discard the TM-SDU, i.e. it shall use the normal procedure. 

A special procedure shall apply for a message with "steal immediately" if the stealing repeats flag is set. 

Then the MS -MAC shall repeat the message on STCH, sending the message once per frame in successive traffic frames 
(i.e. frames 1 to 17) on the assigned uplink channel, until either: 

a) it has sent the message N.214 times (including the first transmission); or 

b) it has stopped transmitting traffic, e.g. as a result of a higher layer message or after checks on the 
ACCESS-ASSIGN PDU; or 

c) it receives a TMA-CANCEL request primitive from the higher layers instructing it to abort transmission of the 

message. 
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In cases a) and b), the MS-MAC shall regard the requested procedure as complete and shall discard the TM-SDU. In 
case c), the MS-MAC shall cease attempting to send the message and shall discard the TM-SDU (see also 
clause 23.5.3). 

While the MS-MAC is performing the "stealing repeats" mechanism described above, it shall over-ride the normal 
monitoring pattern information, and shall attempt to receive and decode the downlink assigned channel in every TDMA 
frame. For a multi-slot channel, and if the MS is not frequency full duplex, the MS shall transmit only in the lowest 
numbered uplink slot appropriate to the assigned channel, sending its message in that slot. It shall attempt to receive and 
decode at least the lowest numbered downlink slot appropriate to the assigned channel in all frames 1 to 17, and all slots 
appropriate to the assigned channel in frame 18 (within the constraints of linearization and transmission requirements). 

If the MS-MAC stops the requested procedure on criterion a) or c) above then it shall continue to use the modified rules 
for receiving and decoding the downlink channel for the T.251 TDMA frames following the N.214'th transmission of 
the message. 

NOTE 1 : The stealing repeats flag may be used by the higher layers to trigger this special stealing method in the 
MAC. This method is intended for signalling at the end of an uplink traffic transmission, for 
U-TX CEASED or possibly U-DISCONNECT. It provides a faster procedure for signalling the end of 
traffic transmission in case of propagation errors. Firstly, it allows more frequent repeats of the message. 
Also, the method of modifying the normal monitoring pattern and the structure of a multi-slot channel 
enables a faster response from the BS. 

NOTE 2: This special procedure affects MAC operation only; the LLC re-transmission protocol is unchanged. The 
MAC should issue the TMA-REPORT indication primitive to the LLC only after the first transmission of 
the message. 

23.8.4.1 .4 Reception on uplink STCH 

This clause describes the procedure for BS reception on uplink slots that have been assigned for traffic. 

The training sequence in each slot shall indicate whether stealing has occurred. 

For normal training sequence 1 (i.e. SF = 0), the receiving BS shall assume that the slot contains only TCH. 

For normal training sequence 2 (i.e. SF = 1), the first half slot shall be assumed to be STCH. Then the MAC PDU type 
shall indicate whether the first half slot was stolen for C-plane signalling (MAC-DATA PDU) or for U-plane signalling 
(MAC-U-SIGNAL PDU). The receiving BS shall inspect the MAC header(s) to discover whether the second half slot is 
also stolen. 

• For U-plane signalling, the "second half slot stolen flag" shall indicate whether the second half slot is stolen. 

• For C-plane signalling, PDU dissociation may be necessary within the first half slot. 

• If the last PDU (or only PDU) in the first half slot is a MAC-DATA PDU containing "Length indication" not 
equal to 11 IIIO2 nor 11 11 II2, then the BS shall assume that the second half slot is not stolen. 

• If the last PDU (or only PDU) in the first half slot is a MAC-DATA PDU containing "Length indication" 

= 111 1 IO2 or 1 1 1 1 1 12, the BS shall assume that the second half slot is stolen. Also, for "Length indication" 
= IIIIII2, the BS shall assume the start of fragmentation and shall store the TM-SDU fragment. 

If the second half slot is not stolen, the BS shall interpret the second half slot as TCH. 

If the second half slot is stolen, the BS shall interpret the second half slot as STCH. Then the MAC PDU type shall 
indicate whether the second half slot was stolen for C-plane signalling (MAC -DATA or MAC-END PDU) or for 
U-plane signalling (MAC-U-SIGNAL PDU). For C-plane signalling, PDU dissociation may be necessary within the 
second half slot. 

In the case of fragmentation: If the second half slot is not decodeable, or if the second half slot does not include a 
MAC-END PDU, then the BS should discard the first fragment. Otherwise, it shall append the fragment from the 
MAC-END PDU to the already received fragment and shall assume that the received TM-SDU is complete. 
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23.8.4.2 Downlink stealing 

23.8.4.2.1 Transmission on downlinl^ STCH 

The BS may steal from a traffic circuit to send C-plane signalling messages on the downlink, either to the MS(s) 
receiving the traffic or to other MSs on the channel. However, the BS designer should note that frequent stealing would 
degrade the quality of the circuit, especially for circuit mode data calls. Also, it is recommended that, when the BS 
requires to steal, it steals from TCH in preference to overwriting U-plane signalling. This recommendation applies 
particularly to end-to-end encrypted calls. 

Valid PDUs for C-plane STCH on the downlink are: 

• MAC-RESOURCE PDU: first or second half slot; 

• SYSINFO PDU: first or second half slot; 

• ACCESS-DEFINE PDU: first or second half slot; 

• MAC-END PDU: second half slot only (final fragment). 
The appropriate PDU for U-plane STCH is: 

• MAC-U-SIGNAL PDU: first or second half slot. 

The downlink MAC-U-SIGNAL PDU should be identical to that received from the transmitting station, except that the 
setting of the "second half slot stolen flag" may be changed when appropriate. 

The MAC header of a MAC-U-SIGNAL PDU sent in a first half slot shall indicate whether the second half slot is also 
stolen, using the second half slot stolen flag. If the second half slot is stolen, it may contain either U-plane or C-plane 
signalling (as indicated by the first MAC header in the second half slot). 

For C-plane stealing within the first half slot, PDU association may be used. The PDU type or "Length indication" in 
the last PDU (or only PDU) in the first half slot shall indicate whether the second half slot is also stolen. 

i) TMB-SAP PDU (SYSINFO or ACCESS -DEFINE): second half slot not stolen. 

Then the second half slot shall contain TCH (MAC -TRAFFIC PDU). 
ii) MAC -RESOURCE PDU with "Length indication" < OIOOOO2: second half slot not stolen. 

Then the second half slot shall contain TCH (MAC -TRAFFIC PDU). 

iii) MAC -RESOURCE PDU with "Length indication" = 1 1 1 1 IO2: second half slot stolen, 

no fragmentation. 

Then the second half slot may contain either U-plane or C-plane signalling (as indicated by the first MAC 
header in the second half slot). For C-plane signalling, PDU association may be used within the second half 
slot. 

iv) MAC -RESOURCE PDU with "Length indication" = 1111112: second half slot stolen, 

start of fragmentation. 

Then the final fragment should be sent in the second half slot, using the MAC -END PDU. PDU association 
may be used within the second half slot. 

NOTE 1: The BS may use the Null PDU as a dummy C-plane message on STCH, in either the first half slot, second 
half slot or both. As always, "Address type" OOO2 in the MAC-RESOURCE PDU indicates a downlink 
Null PDU. In the first half slot, the "Length indication" indicates whether or not the second half slot is 
stolen. 

NOTE 2: The SYSINFO PDU cannot be sent in the first half slot if the second half slot is also to be stolen. 

If the second half slot is to be stolen, the ACCESS-DEFINE PDU can be included in the first half slot if 
required, but not as the last PDU (or only PDU) in the first half slot. 
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23.8.4.2.2 Reception on downlink STCH 

This procedure shall be used by all MSs that are receiving the downlink channel. 

All MSs that are receiving the channel shall check whether C-plane messages are addressed to itself and, if so, shall 
process the message and deliver any TM-SDU to the LLC. Only MSs that are currently permitted to process received 
traffic shall pass the TCH, and the TM-SDU in U-plane signalling (MAC-U-SIGNAL PDU), to the U-plane application. 

The training sequence in each slot shall indicate whether stealing has occurred. 

For normal training sequence 1 (i.e. SF = 0), the receiving MS shall assume that the slot contains only TCH. 

For normal training sequence 2 (i.e. SF = 1), the first half slot shall be assumed to be STCH. Then the MAC PDU type 
shall indicate whether the first half slot was stolen for C-plane (TMA-SAP/TMB-SAP) or for U-plane (TMD-SAP) 
signalling. The receiving MAC shall inspect the MAC header(s) to discover whether the second half slot is also stolen. 



• 



• 



For U-plane signalling, the "second half slot stolen flag" shall indicate whether the second half slot is stolen. 

For C-plane signalling, PDU dissociation may be necessary within the first half slot. 

If the last PDU (or only PDU) in the first half slot is a TMB-S AP PDU, or a MAC-RESOURCE PDU (or Null 
PDU) containing "Length indication" not equal to 1111 IO2 nor 1 1 1 1 1 12, then the MS shall assume that the 
second half slot is not stolen. 

If the last PDU (or only PDU) in the first half slot is a MAC-RESOURCE PDU (or Null PDU) containing 
"Length indication" = 1111102orllllll2, the MS shall assume that the second half slot is stolen. Also, for 
"Length indication" = IIIIII2, the addressed MS(s) shall assume the start of fragmentation and shall store the 
TM-SDU fragment. 

If the first half slot is not decodeable, the MS designer should choose an appropriate method for processing the second 
half of the slot. 

EXAMPLE: The MS might make a first assumption that the second half slot is stolen, but revise that decision if 
the CRC fails. (This method could be particularly useful at the start of an encrypted transmission 
when encryption synchronization might be sent in both halves of the slot.) Otherwise the MS could 
treat the second half slot as "CRC fail" TCH. 

If the second half slot is not stolen, the receiving MS shall interpret the second half slot as TCH. 

If the second half slot is stolen, the MS shall interpret the second half slot as STCH. Then the MAC PDU type shall 
indicate whether the second half slot was stolen for C-plane (TMA-SAP/TMB-SAP) or U-plane (TMD-SAP) signalling. 
If the second half slot is not decodeable, the MS should regard the MAC block as C-plane signalling with CRC failure. 

In the case of C-plane signalling, PDU dissociation may be necessary within the second half slot. 

If the second half slot is not decodeable, or if the second half slot does not include a MAC -END PDU, an MS -MAC 
that stored a first fragment in the first half slot shall discard that fragment. Otherwise, it shall append the fragment from 
the MAC-END PDU to the already received fragment, and shall dehver the complete TM-SDU to the LLC. 

23.8.5 BS operation 

For traffic slots received on the uplink: 

a) for normal training sequence 1, channel decoding (and re-encoding) may be performed at the BS, allowing 
error correction for multiple hops; 

b) channel decoding (and re-encoding) should be performed at the BS in the case of normal training sequence 2, 
in order that the BS can recognize C-plane stealing; 

c) when a half slot has been stolen on the uplink for C-plane signalling, the BS should replace the stolen half slot 
(e.g. with another C-plane message or with the Null PDU or with substitution traffic) before transmission on 
the downlink. 
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The BS should pass the U-plane signalling and TCH on towards the destination. The timing and ordering and half-slot 
pairing of the U-plane information (signalling and TCH) shall be preserved. The BS may replace (i.e. overwrite) 
U-plane information when performing C-plane stealing, but shall not move the replaced U-plane information to a 
different position. 

If the BS does not receive data from the sending MS, e.g. in the case of U-plane DTX, it should still transmit on the 
downlink channel to the receiving MS(s). For example, it could fill the slot with two stolen half slots each containing 
the C-plane Null PDU, or it could fill the slot with substitution traffic. 

If the BS is decoding and re-encoding the traffic for a circuit mode data call with an interleaving depth of N = 4 or 8 
then: 

i) the BS should delay U-plane signalling by N - 1 traffic frames before transmission on the downlink; 

NOTE 1: This procedure for N = 4 or 8 means that the BS transmits the U-plane data stream with the U-plane 
signalling in the same position as when the MS transmitted it. This position may be important if the 
U-plane signalling is carrying end-to-end encryption synchronization. 

The need for the procedure arises because the de-interleaving process causes the circuit mode data to be 
delayed by N - 1 traffic frames relative to the U-plane signalling. The receiving MS's procedure (see 
clause 23.8.3.2) takes account of the relative delay over the air interface if the BS does not de-interleave 
the traffic before transmission on the downlink. The BS needs to compensate for the additional relative 
delay introduced by its de-interleaving and re-interleaving of the traffic. 

ii) after a U-TX CEASED or U-DISCONNECT PDU has been received from the transmitting MS, the BS should 
ensure that it has been able to issue N - 1 slots containing tail bits to the lower MAC at the end of the data 
transmission (on each allocated slot in the case of a multi-slot channel) before sending the D-TX CEASED, 
D-RELEASE or D-DISCONNECT PDU to receiving MS(s). 

NOTE 2: These tail bits are needed to complete the interleaving of the circuit mode data that has been received 
from the transmitting MS. 

Some examples of scenarios for call set-up and channel usage for circuit mode calls are illustrated in annex D. 
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28 TETRA Packet Data Protocol 

Clause 28 defines the TETRA Packet Data Protocol (PDP) for packet data operation. The TETRA packet data service is 
built on top of the Mobile Link Entity (MLE) defined in clauses 17 and 18 of the present document. 

NOTE: The TETRA packet data service is separate from the Connection Oriented Network Service (CONS) and 
the Specific Connectionless Network Service (SCLNS) which were defined in clauses 24 to 27 of the 
ETS 300 392-2 edition 1. 

The TETRA packet data service provides mechanisms to convey different higher layer protocols. The present document 
supports the following network layer protocols: 

• Internet Protocol (IP), versions 4 and 6. 

TETRA packet data extends TETRA to act as an IP subnet. This enables application programmers to build their 
applications in a well-standardized environment. 

At the MS side the IP and the higher layers on top of it may be located at: 

• MTO; 

• TE2 where the protocol used between TE2 and MT2 is defined in EN 300 392-5 [7]; 

• TE where the protocol used between TE and MTO is outside the scope of the present document 
and EN 300 392-5 [7]; 

• MEX layer (clause 30). 

The implementation of the SwMI's IP routing and relaying as well as the connection to external networks is outside the 
scope of the present document. 

The figure 28.1 illustrates the usage of TETRA packet data when the application is located in MTO. 
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Figure 28.1 : Usage of TETRA packet data for MTO IP application 

The figure 28.2 illustrates the usage of TETRA packet data when the applications use IP protocol and are located in 
TE2. Mapping between PEI DLL (MT2) and MEX is via the TNMXPI-SAP (see clause 30). 
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Figure 28.2: Usage of TETRA packet data for TE2 IP application 

The Wireless Application Protocol (WAP) architecture, see WAP2.0 [i.9], defines a framework to meet the challenges 
of the advanced services, differentiation and fast/flexible service creation in wireless networks. The WAP defines a set 
of protocols in transport, session and application layers. 

The upper layers of WAP will be independent of the underlying wireless network, while the transport layer should be 
adapted to specific features of underlying services. This adaptation to TETRA packet data is, however, outside of the 
scope of the present document. When used in conjunction with the TETRA packet data service, it is recommended that 
WAP be located on top of UDP/IP. Figure 28.3 illustrates the recommended usage of TETRA packet data when the 
application is a WAP application and it is located in MTO. 
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Figure 28.3: Usage of TETRA packet data for MTO WAP application 

NOTE: The MEX layer, defined in clause 30 of the present document, may be used to enhance the interface 
between SNDCP and its user applications. 
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28.1 Subnetwork Dependent Convergence Protocol (SNDCP) 
overview 

The Subnetwork Dependent Convergence Protocol (SNDCP) is a TETRA specific network layer protocol that has two 
main functions: 

1) to negotiate and maintain PDP contexts between an MS and the SwMI. A unique primary PDP context is 
established for each PDP address active (i.e. which requires packets to be routed to it) on the network. The 
primary PDP context activation procedure involves the binding of a PDP address to a TETRA ITSI and also 
the optional negotiation of compression algorithms and QoS parameters to be used during data transfer. 
Secondary PDP context activation involves binding the secondary PDP context to the PDP address of a 
primary PDP context and also the optional negotiation of compression algorithms and QoS parameters to be 
used during data transfer. 

2) to control PDP data transfer between MS and SwMI. Data transfer is unacknowledged (i.e. SNDCP does not 
perform retransmissions); however, SNDCP allows the service user to select the acknowledged or 
unacknowledged layer 2 services for data transfer over the air interface. SNDCP provides mechanisms by 
which data may be compressed before being transmitted over the air interface. 

Figure 28.4 describes the protocol model for TETRA packet data and the SNDCP position in it. 
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NOTE: Legend: 

Subnetwork Dependent Convergence Protocol (SNDCP): TETRA specific Networl< layer protocol that 

shall be used to negotiate and maintain PDP contexts between IVIS and SwMI 

Mobile Link Entity (MLE): MLE protocol discriminator entity (data transfer) routes TETRA Packet data 

signalling and data to corresponding TETRA Packet data SAP at the peer entity (SwMI/MS). 

Logical Link Control (LLC): This layer provides a logical link. 

Medium Access Control (MAC): This controls the access signalling (request and grant) procedures for 

the radio channel, and the mapping of LLC frames onto the TETRA physical channel. 

Air Interface layer 1 (AI-1): As defined in the present document. 

Figure 28.4: Subnetwork Dependent Convergence Protocol (SNDCP) 

Before a MS may gain access to any SNDCP services, it firstly goes through a packet data registration procedure, called 
PDP context activation. PDP context activation is initiated by the MS. The MS may activate primary PDP context and 
secondary PDP contexts. Activation of a primary PDP context involves the negotiation of a PDP address (e.g. an IPv4 
address) and other parameters to be used during data transfer. Each primary PDP context should have a different PDP 
address. When the MS has established one or more primary PDP contexts, it may request establishment of secondary 
PDP contexts. A secondary PDP context derives its PDP address from a primary PDP contexts and is used by the SwMI 
to differentiate the QoS given to different types of packets being sent to the same PDP address. The SwMI uses a QoS 
filter to determine if a downlink packet should use a secondary PDP context. If a downlink packet does not match the 
PDP address and the QoS filter of any secondary PDP context, the SwMI should instead send the packet via the primary 
PDP context for the relevant PDP address. The MS SNDCP may also specify a differentiated services field ("diffserv") 
filter for a secondary PDP context. The SwMI may inspect the lower 5 bits (4 to 0) of the 6-bit Differentiated Services 
Code Point (DSCP) in downlink IP packet headers and route the packets through a secondary PDP context with a 
matching diffserv filter. 

If the MS does not specify a QoS filter during activation of a secondary PDP context, the SwMI should generate an 
automatic QoS filter. 
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EXAMPLE: The SwMI may generate an automatic QoS filter by recording the source port numbers and 

NS APIs of uplink TCP/IP and UDP/IP packets received via secondary PDP contexts and use this 
to filter downlink packets on the basis of the downlink packets' destination IP addresses and 
destination ports. 

PDP data transfer normally takes place over an assigned secondary control channel (assigned SCCH), termed in this 
specification a Packet Data CHannel (PDCH). An advanced link is set up before data transfer may begin on the PDCH 
using the acknowledged layer 2 service. When a MS has data to transfer, it implicitly requests permission to switch to 
the PDCH. If accepted, the SwMI normally responds with a channel allocation, directing the MS to a PDCH. 

NOTE: The SwMI may allow the MS to use the MCCH for the exchange of packet data. 

The protocol for SNDCP is described in terms of a state machine. There are three main states which are defined for both 
the MS and SwMI, namely READY, STANDBY and IDLE. 

READY state typically implies a MS is located on a PDCH and is currently engaged in data transfer or has recently 
(defined by a timer) been engaged in packet data transfer. 

STANDBY state implies a MS is no longer on a PDCH i.e. the MS has not recently (defined by a timer) been engaged 
in data transfer. 

IDLE state implies that a MS has no PDP contexts activated. 

A more complete description of SNDCP is given in the following clauses. 

28.2 SNDCP service description 

28.2.1 Introduction 

This clause describes the services offered by the Subnetwork Dependent Convergence Protocol (SNDCP) entity for the 
voice plus data TETRA layer 3 air interface. 

28.2.2 Services offered 

SNDCP shall be a service provider for packet data users. The services shall be made available through the SNDCP 
Service Access Point (SN-SAP). The SNDCP procedures and protocol description are defined in clauses 28.3 and 28.4. 

The services offered shall be: 

PDP context activation and PDP context deactivation; 

PDP context modification; 

Negotiation and modification of QoS requirements; 

Packet Data CHannel (PDCH) handling; 

Multiplexing of N-PDUs from one or several higher protocol entities onto a single layer 2 connection; 

Mapping of SN primitives received from the network layer into corresponding MLE-UNITDATA request 
primitives to be passed to the MLE; 

If data priority is not supported: 

management of the delivery sequence according to the PDU priority of SN-UNITDATA request and 
SN-DATA request primitives; 

If data priority is supported: 

management of the delivery sequence according to the PDU priority and data priority of 
SN-UNITDATA request and SN-DATA request primitives; 

mapping of N-PDU data priorities into a priority for reserved access; 
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Compression and recovery of redundant protocol control information (e.g. TCP/IP header). Header 
compression is performed independently for each NSAPI; 

Compression and recovery of redundant user data. Data compression is performed independently for each 
NSAPI; 



• 



Interface to MEX mediated applications and applications which bypass MEX (see clause 30). 

28.2.3 Service Primitives 

The services shall be provided through primitives at the service access point SN-SAP. This clause describes the 
primitives and their parameters. 

Mapping of various protocols to the SNDCP operation is defined with respect to an abstract underlying service. The 
underlying service consists of the following primitives: 

SN-DATA {Request, Indication}; 

SN-DELIVERY {Indication}; 

SN-NSAPI ALLOC {Request, Indication, Confirm}; 

SN-NSAPI CONFIGURE {Request, Confirm}; 

SN-NSAPI DEALLOC {Request, Indication}; 

SN-NSAPI MODIFY {Request, Indication, Confirm}; 

SN-QOS {Request, Indication}; 

SN-UNITDATA {Request, Indication}; 

SN-PAGE { Request, Indication, Response, Confirm}. 

28.2.3.1 Primitive descriptions 

In parameter descriptions: 

• M = Mandatory: 

• O = Optional: 

• - = Not allowed. 
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SN-DATA request/indication: SN-DATA primitive is used for acknowledged data transfer service at the LLC. The 
receipt of data shall be confirmed by the LLC layer. 

Parameters of the primitive shall be as shown in table 28. L 

Table 28.1 : Parameters for the primitive SN-DATA 



Parameter 


Request 


Indication 


NSAPI 


M 


M 


Handle 


M 


- 


PDU priority 


(see note 1 ) 


- 


Data priority 


(see note 2) 


- 


Data importance 


(see note 3) 


- 


Schedule surplus flag 


(see note 4) 


- 


N-PDU 


M 


M 


NOTE 1 : If PDU priority is not given in the primitive, then the value assigned by 

the SwIVII during context activation is used. 
NOTE 2: If the data priority is not given in the primitive, then the value 

"undefined" should be assumed by SNDCP. 
NOTE 3: If the data importance is not given in the primitive, then the value 

"low" should be assumed by SNDCP. 
NOTE 4: If the schedule surplus flag is not given in the primitive then the value 

"not surplus to schedule" should be assumed by SNDCP. 



SN-DELIVERY indication: SN-DELIVERY primitive is used to indicate that SNDCP has completed its transmission 
of the N-PDU in a SN-DATA request primitive (success/failure/deleted or cancelled by SNDCP) or SN-UNITDATA 
request primitive (failure/deleted or cancelled by SNDCP). 

Parameters of the primitive shall be as shown in table 28.2. 

Table 28.2: Parameters for the primitive SN-DELIVERY 



Parameter 


Indication 


Handle 


M 


Delivery report 


M 



£75/ 



897 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



SN-NSAPI ALLOC request/indication/confirm: SN-NSAPI ALLOC primitive is used to set NSAPI into use. 
Parameters of the primitive shall be as shown in table 28.3. 

Table 28.3: Parameters for the primitive SN-NSAPI ALLOC 



Parameter 


Request 
(MS only) 


Indication 
(SwMI only) 


Confirm 
(MS only) 


NSAPI 


M 


M 


M 


NSAPI alloc report 


- 


- 


M 


PDP type 


M 


M 


C (see note 3) 


PDP address 


C (see note 1 ) 


M 


C (see note 2, see note 
3) 


DCOMP negotiation 








(see note 3) 


PCOIVIP negotiation 








(see note 3) 


NSAPI alloc reject cause 


- 


- 


C (see note 4) 


PDU priority max 


- 


- 


C (see note 3) 


NSAPI data priority 


(see note 6) 


- 


- 


IVlaximum transmission unit 


- 


- 


M 


IVIobile IPv4 information 


- 


- 


C (see notes 3 and 5) 


NSAPI QoS negotiation 








(see note 3) 


NOTE 1 : Conditional on PDP type. PDP address not present in case of IPv4 dynamic address 

negotiation or IPv6. 
NOTE 2: Conditional on PDP type. PDP address not present in case of IPv6 or Mobile IPv4 FA care of 

address requested. 
NOTE 3: Conditional on NSAPI alloc report. Not present in case of NSAPI alloc report set to "Failure". 
NOTE 4: Conditional on NSAPI alloc report. Present in case of NSAPI alloc report set to "Failure". 
NOTE 5: Conditional on PDP type. Present if PDP type set to IVIobile IPv4. 
NOTE 6: If the "NSAPI data priority" is not given in the primitive, then the value "undefined" should be 

assumed by SNDCP. 



SN-NSAPI CONFIGURE request/confirm: SN-NSAPI CONFIGURE primitive is used to make local modifications 
to the characteristics of an activated NSAPI. 

Parameters of the primitive shall be as shown in table 28.4. 

Table 28.4: Parameters for the primitive SN-NSAPI CONFIGURE 



Parameter 


Request 


Confirm 


NSAPI 


M 


M 


NSAPI data priority 


M 


M 



SN-NSAPI DEALLOC request/indication: SN-NSAPI DEALLOC primitive is used to withdraw NSAPI from use. 
Parameters of the primitive shall be as shown in table 28.5. 

Table 28.5: Parameters for the primitive SN-NSAPI DEALLOC 



Parameter 


Request 


Indication 


Deactivation type 


M 


M 


NSAPI 


C (see note) 


C (see note) 


NOTE: Not present if Deactivation Type is set to "Deactivate All NSAPIs". 
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SN-NSAPI MODIFY request/indication/confirm: SN-NSAPI MODIFY primitive is used to modify the 
characteristics of an activated NS API which have been agreed with the SwMI. 

Parameters of the primitive shall be as shown in table 28.6. 

Table 28.6: Parameters for the primitive SN-NSAPI lUIODIFY 



Parameter 


Request 


Indication 


Confirm 


NSAPI 


M 


M 


M 


NSAPI modify report 


- 


- 


M 


NSAPI modify reject cause 


- 


- 


C (see note 1) 


NSAPI QoS negotiation 
(see note 3) 








(see note 2) 


Schedule availability 


- 





- 


NSAPI usage (see note 3) 





- 


- 


NOTE 1 : Conditional on NSAPI modify report. Present only in case of NSAPI modify report set to 

"failure". 
NOTE 2: Conditional on NSAPI modify report. Not present in case of NSAPI modify report set to "failure". 
NOTE 3: Only one of "NSAPI QoS negotiation" and "NSAPI usage" should be included in a single 

primitive, not both. 



SN-QOS request/indication: SN-QOS primitive is used to negotiate about QoS to the peer entity. 
Parameters of the primitive shall be as shown in table 28.7. 

Table 28.7: Parameters for the primitive SN-QOS 



Parameter 


Request 


Indication 


QoS requested 


M 


M 


QoS minimum 


M 


- 


QoS negotiated 


- 


M 


QoS negotiation result 


- 


M 


NOTE: It is recommended that this primitive is used only to set parameters 
within the MS SNDCP entity, to be used at a later stage during 
advanced link setup negotiation. This primitive should not in itself 
trigger the establishment or resetting of the advanced link. 



NOTE: The SN-QOS request primitive is retained for backward compatibility with previous versions of this 
document, and is applicable only to 7t/4-DQPSK modulation. The optional NSAPI QoS negotiation 
parameter included in the SN-NSAPI ALLOC and SN-NSAPI MODIFY primitives has more general 
applicability, and should be used instead of the SN-QOS request primitive. 
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SN-UNITDATA request/indication: SN-UNITDATA primitive is used for unacknowledged data transfer service at 
the LLC. The receipt of data is not confirmed by the SNDCP or lower layers. 

Parameters of the primitive shall be as shown in table 28.8. 

Table 28.8: Parameters for the primitive SN-UNITDATA 



Parameter 


Request 


Indication 


NSAPI 


M 


M 


Handle 


M 


- 


PDU priority 


(see note 1 ) 


- 


Data priority 


(see note 2) 




Data importance 


(see note 3) 




Schedule surplus flag 


(see note 4) 




N-PDU 


M 


M 


NOTE 1 : If PDU priority is not given in the primitive, then the value assigned 

during context activation is used. 
NOTE 2: If the data priority is not given in the primitive, then the value 

"undefined" should be assumed by SNDCP. 
NOTE 3: If the data importance is not given in the primitive, then the value 

"low" should be assumed by SNDCP. 
NOTE 4: If the schedule surplus flag is not given in the primitive then the value 

"not surplus to schedule" should be assumed by SNDCP. 



SN-PAGE request/indication/response/confirm: SN-PAGE primitive is used as part of the TETRA packet data 
paging mechanism. 

Parameters of the primitive shall be as shown in table 28.9. 

Table 28.9: Parameters for the primitive SN-PAGE 



Parameter 


Request 
(SwMI only) 


Indication 
(IMS only) 


Response 
(MS only) 


Confirm 
(SwMI only) 


NSAPI 


M 


M 


M 


M 


Reply requested 


M 


M 


- 


- 


PD service status 


- 


- 


M 


M 



28.2.3.2 Parameter descriptions 

CONTEXT_READY time = 
track READY timer; 
200 ms; 
500 ms; 
700 ms; 

1 s; 

2 s; 

3 s; 
5 s; 
10 s; 
20 s; 
30 s; 
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• 60s; 

• 120 s; 

• 180 s; 

• 300 s. 
Data class = 

• Real-time class - layer 2 link optimized for data which cannot tolerate delivery delay (late packets discarded 
by the receiving application); 

• Telemetry class - layer 2 link optimized for intermittent data which can tolerate moderate delivery delay and 
packet loss; 

• Background class - layer 2 link optimized for data which are intolerant of packet loss. 
Data importance = 

• Low; 

• Medium; 

• High. 

NOTE 0: In circumstances where the MS SNDCP decides to delete or cancel untransmitted N-PDUs, 

"data importance" allows the MS SNDCP to preferentially delete or cancel N-PDUs containing 
lower-importance data. Data importance is not transmitted over the air interface. 

Data priority = 

Lowest data priority; 
etc.; 

7 Highest data priority. 
DCOMP negotiation = 

• This parameter may contain several different data compression methods, such as 

ITU-T Recommendation V.42bis [27], and their parameters negotiated with the peer entity. 

Deactivation type = 

• Deactivate all NSAPIs; 

• Deactivate NSAPl given in the primitive. 
Delay class = 

• Low; 

• Moderate; 

• High; 

• Unpredictable. 
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Table 28.10 defines the meaning of the delay class values. 



Table 28.10: Packet delays for different delay classes 





N-PDU size <1 28 octets 


128 < N-PDU size <1 024 
octets 


1 024 < N-PDU size < 2 002 
octets 


Delay Class 


lUlean transfer 
delay (s) 


95 percentile 
delay (s) 


lUlean transfer 
delay (s) 


95 percentile 
delay (s) 


Mean transfer 
delay (s) 


95 percentile 
delay (s) 


Low 


< 1 


<3 


<3 


<7 


<5 


<10 


Moderate 


<5 


<25 


<15 


<75 


<30 


<150 


High 


<50 


<250 


<75 


<375 


<110 


<560 


Unpredictable 


Undefined 


Undefined 


undefined 


undefined 


undefined 


undefined 



NOTE 1 : For packets sizes up to 1 024 octets, the delays for moderate and high classes match those for GPRS, see 
TS 122 060[i.l0]. 

NOTE 2: Real-time class data requires the low delay class; if real-time class data is specified, the low delay class 
should be assumed by default. 

NOTE 3: The delay values are for MS to MS communication in a single network (SwMI) including random access 
delay. 

Delivery report = 

• Success; 

• Failure; 



Deleted or cancelled by SNDCP. 



DSCP = 



differentiated services code point. 



Handle = 



• Defines the handle used to generate a mapping between SN-DATA or SN-UNITDATA request primitives and 
SN-DELIVERY indication primitives. 

Maximum transmission unit = 

• This is the maximum size of N-PDU which may be presented by the MS service user to SNDCP for transport 
over the air interface. This typically represents the maximum size of IP packet (prior to adding SNDCP header 
and performing compression) which may be carried over the air-interface. 

Mean active throughput = 

• This is the mean throughput of N-PDUs expected by the SNDCP service user while the PDP context is 
actively transmitting or receiving data (i.e. while the PDP context's CONTEXT_READY timer is active, if 
supported, or while the READY timer is active if CONTEXT_READ Y timers are not supported). 

• The values are as for minimum peak throughput. 
Mean throughput = 

• This is the mean throughput of N-PDUs expected by the SNDCP service user, averaged over the expected 
lifetime of the PDP context. It is given in units of octets/hour. 

100 (-0,22 bits/s) 

200 (-0,44 bits/s) 

500 (-1,11 bits/s) 

1 000 (-2,2 bits/s); 
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2 000 (-4,4 bits/s); 
5 000(~ll,lbits/s); 
10 000 (-22 bits/s); 
20 000 (-44 bits/s); 
50 000 (-111 bits/s); 
100 000 (-0,22 kbit/s); 
200 000 (-0,44 kbit/s); 
500 000 (-1,11 kbit/s); 

1 000 000 (-2,2 kbit/s); 

2 000 000 (-4,4 kbit/s); 
5 000 000 (-11,1 kbit/s); 
10 000 000 (-22 kbit/s); 
20 000 000 (-44 kbit/s); 
50 000 000 (-111 kbit/s); 
Best effort. 

NOTE 4: These values follow those given for GPRS, see EN 301 344 [i. 1 1]. 

Minimum peak throughput = 

• This is the minimum peak throughput of N-PDUs in units of octets/s requested or offered for a particular PDP 
context. This is the minimum throughput required when the PDP context is at its most active; if the peak rate 
available is lower than this, the application may not be usable (though the application may be capable of using 
a higher rate than this). 

< 1 000; 

> 1 000; 

> 2 000; 

> 4 000; 

> 8 000; 

> 16 000; 

> 32 000; 

> 64 000. 

NOTE 5: The following examples show methods of providing the requested peak throughput in a reliable channel: 

a peak throughput less than 1 000 octets/s can be provided by any PDCH; 

a peak throughput > 1 000 octets/s requires 4-QAM 25 kHz (3-, 4-slot), 7t/4-DQPSK (2-, 3-slot), 
etc.; 

a peak throughput > 2 000 octets/s requires 4-QAM 50 kHz (3-, 4-slot), 7t/4-DQPSK (4-slot), etc.; 

a peak throughput > 4 000 octets/s requires 4-QAM 100 kHz (3-, 4-slot), 4-QAM 150 kHz (2-slot), 
etc.; 

a peak throughput > 8 000 octets/s requires 4-QAM 150 kHz (3-, 4-slot); 
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■ a peak throughput > 16 000 octets/s requires 16-QAM 150 kHz (4-slot), etc.; 

■ a peak throughput > 32 000 octets/s requires 64-QAM r = V2, 150 kHz (4-slot), etc.; 

■ a peak throughput > 64 000 octets/s requires 64-QAM r = 1, 150 kHz (4-slot). 
Mobile IPv4 Information = 

• Information specific to Mobile IPv4 operation. 
N-PDU = 

• Any number of bits needed to carry a Network layer protocol PDU. 
NSAPI = 

Reserved; 

1 Free; 
etc.; 

14 Free; 

15 Reserved. 
NSAPI alloc reject cause = 

Undefined; 

MS not provisioned for Packet Data; 

IPv4 not supported; 

IPv6 not supported; 

IPv4 dynamic address negotiation not supported; 

IPv6 stateful address autoconfiguration not supported; 

IPv6 stateless address autoconfiguration not supported; 

Dynamic address pool empty; 

Static address not correct; 

Static address in use; 

Static address not allowed; 

Static IP address congestion; 

TETRA Packet Data not supported on this location area; 

TETRA Packet Data not supported on this network; 

Temporary rejection; 

Packet Data MS Type not supported; 

SNDCP version not supported; 

Mobile IPv4 not supported; 

Mobile IPv4 Co-located Care of Addresses not supported; 

Maximum allowed PDP contexts per ITSI exceeded; 
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• User authentication failed; 

• Activation rejected by external PDN; 

• Access point name index not correct; 

• No response from network; 

• Bad response from network; 

• NSAPI not available; 

• NSAPI already allocated; 

• Requested minimum peak throughput not available; 

• Scheduled access not supported; 

• Requested schedule not available; 

• Requested QoS not available; 

• Secondary PDP contexts not supported; 

• Primary PDP context does not exist; 

• Asymmetric QoS not supported; 

• Automatic QoS filter not supported; 

• Specified QoS filter not supported; 

• QoS filter type not supported; 

• QoS filter not available for primary PDP context. 
NSAPI alloc report = 

• Failure; 

• Success (Note that DCOMP negotiation, PCOMP negotiation and NSAPI QoS negotiation values might be 
changed). 

NSAPI data priority = 

• As data priority. 
NSAPI modify reject cause = 

• Undefined; 

• Temporary rejection; 

• No response from network; 

• Bad response from network; 

• NSAPI not activated; 

• Requested minimum peak throughput not available; 

• Scheduled access not supported; 

• Requested schedule not supported; 

• Requested QoS not available; 
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• Secondary PDP contexts not supported; 

• Primary PDP context does not exist; 

• Asymmetric QoS not supported; 

• Automatic QoS filter not supported; 

• Specified QoS filter not supported; 

• QoS filter type not supported; 

• QoS filter not available for primary PDP context. 
NSAPI modify report = 

• Failure (the NSAPI QoS negotiation parameter was not changed from its previous value); 

• Success (one or more of the items in the NSAPI QoS negotiation parameter were changed from their previous 
values). 

NSAPI QoS negotiation = 

• A set of: QoS for uplink and downlink or for uplink only, QoS for downlink, CONTEXT_READY time, QoS 
filter (only when a secondary PDP context is requested) and scheduled access. 

NSAPI Usage = 

• Schedule paused; 

• PDP context paused. 
PCOMP negotiation = 

• This parameter may contain several different protocol compression methods. They may be one or more of: 
TCP/IP header compression (not available for unacknowledged layer 2 service or real-time class data) and 
IP header compression. 

PD service status = 

• Available for packet data service; 

• Temporarily unavailable for packet data service. 
PDP address = 

• IPv4 address (only when a primary PDP context is being requested); or 

• NSAPI (only when a secondary PDP context is being requested). 
PDP type = 

• IPv4 (static address); 

• IPv4 (dynamic address negotiation); 

• IPv6; 

• Mobile IPv4 - Foreign Agent care of address requested; 

• Mobile IPv4 - Co-located care of address requested; 

• Primary NSAPI (secondary PDP context requested). 
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PDU priority = 

Lowest PDU priority; 
etc.; 

7 Highest PDU priority. 
PDU priority max = 

• As PDU priority. 
Port = 

• A port number (0 to 65535). 
Port range = 

• Lower limit of a range of port numbers (0 to 65535); 

• Upper limit of a range of port numbers (0 to 65535). 

QoS filter = 

A set of: QoS filter operation, QoS filter type and one of: port, port range or DSCP (port, port range and DSCP not 
required when QoS filter type = automatic QoS filter). 

QoS filter operation = 

• Add to any existing QoS filter for the specified PDP context; 

• Replace any existing QoS filter for the specified PDP context; 

• Remove from any existing QoS filter for the specified PDP context. 
QoS filter type = 

• Automatic QoS filter; 

• All types of ports; 

• UDP ports; 

• TCP ports; 

• Diffserv. 
QoS for downlink = 

• A set of: data class, minimum peak throughput, mean throughput, mean active throughput, delay class and 
reliability class. 

QoS for uplink and downlink or for uplink only = 

• A set of: data class, minimum peak throughput, mean throughput, mean active throughput, delay class and 
reliability class. 

QoS minimum = 

• As QoS requested. 
QoS negotiated = 

• As QoS requested. 
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QoS negotiation result = 

• Success; 

• Failure; 

• Failure, try again. 

NOTE 6: The QoS requested, QoS minimum and QoS negotiated and QoS negotiation result parameters are 
retained for compatibility with previous versions of this document. The NS API QoS negotiation 
parameter in the SN-NSAPI ALLOC and SN-NSAPI MODIFY request primitives should be used instead, 
if supported. SNDCP requires the information they contain to use scheduled access and to obtain the 
throughput improvements available on D8PSK and QAM channels. 

QoS requested = 

• A set of: 

Advanced link service (unacknowledged, acknowledged): 

Maximum length of N-PDU: 

Number of timeslots used per TDMA frame (1-4): and 

Data transfer throughput (network dependent minimum, 1/32, 1/16, 1/8, 1/4, 1/2, maximum). 
Reliability class = 

• High (uses an acknowledged link with FCS enabled); 

• Moderate (uses an acknowledged link with FCS disabled); 

• Low (uses the unacknowledged basic link, normally with FCS disabled and no retransmissions). 
Table 28. 11 defines the reliability classes. 

Table 28.11 : Definition of reliability classes 



Reliability class 


Lost N-PDU Probability 


Duplicate N-PDU 
Probability 


Out of Sequence 
N-PDU Probability 


Corrupt N-PDU 
Probability 


High 


<io-'^ 


<io-'^ 


<io-^ 


<io-^ 


Moderate 


<io-^ 


<io-'^ 


<io-=' 


<io-^ 


Low (see note 1 ) 


Undefined 


(see note 2) 


(see note 2) 


<io-* 


NOTE 1 : Uses an unacknowledged link. 

NOTE 2: Applies only if each N-PDU is transmitted once. 



NOTE 7: Real-time class data uses the low reliability class. 
Reply requested = 

• SNDCP response required; 

• SNDCP response not required. 
Schedule availability = 

• Available; 

• Cancelled; 

• Suspended. 
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Schedule repetition period = 

• 4 slot durations; 

• 5 slot durations; 

• etc.; 

• 706 slot durations (10 s). 

NOTE 8: A slot has a duration of 85/6 ms. 
Schedule surplus flag = 

• Not surplus to schedule; 

• Surplus to schedule. 
Schedule timing error = 

• < 1 slot duration; 

• < 2 slot durations; 

• < 4 slot durations; 

• < 8 slot durations; 

• < 16 slot durations; 

• < 32 slot durations; 

• < 64 slot durations; 

• < 128 slot durations. 

NOTE 9: A slot has a duration of 85/6 ms. 

NOTE 10:The SwMI sets the earliest timing of successive scheduled slot grants relative to the time of the first slot 
grant. The schedule timing error is the maximum acceptable delay of a scheduled slot grant beyond the 
earliest time of a scheduled slot grant. The SNDCP application should not propose a schedule timing error 
which is greater than the schedule repetition period. 

Scheduled Access = 

• A set of: 

schedule repetition period; 

schedule timing error; 

scheduled number of N-PDUs per grant; 

scheduled N-PDU size. 

NOTE 11: The scheduled N-PDU size parameter should be repeated as many times as necessary to indicate a size for 
each scheduled N-PDU per grant. 

Scheduled N-PDU size = 

• 1 octet; 

• 2 octets; 

• etc.; 

• 2 002 octets. 
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Scheduled number of N-PDUs per grant = 

• 1; 

• 2; 

• etc.; 

• 7. 

28.2.4 Definition of SNDCP states and state transitions 

The SNDCP activities related to a TETRA MS are characterized by one of eight different SNDCP states: CLOSED, 
IDLE, IDLE-Temporary Break, STANDBY, STANDBY-Temporary Break, RESPONSE- WAITING, READY and 
READY-Temporary Break. The SNDCP activities related to a TETRA SwMI are characterized by one of three different 
SNDCP states: IDLE, STANDBY and READY. 

Each state describes a certain level of functionality and information allocated to the involved entities. The SNDCP state 
relates only to SNDCP activities of a subscriber represented by the ITSI. It is independent of number of PDP contexts 
for that subscriber. 

It is optional for a MS to support multiple PDP contexts. It is also optional for a SwMI to support multiple PDP contexts 
for a single ITSI. 

NOTE: If multiple PDP contexts are used by a single ITSI, then the MS will release all its PDP contexts at the 

same time when entering to state IDLE from state STANDBY. The SwMI may use SwMI originated PDP 
Deactivation procedure in order to control PDP context lifetimes separately. 

28.2.4.1 CLOSED 

CLOSED state is valid for a MS only. In CLOSED state access to the communication resources is unavailable (e.g. due 
to MS not being registered or being temporarily disabled) and SNDCP is not permitted to communicate with its peer 
entity. 

In CLOSED state, the MS must not have any PDP contexts active. 

When entering state CLOSED, the READY, CONTEXT_READY, RESPONSE_WAIT and STANDBY timers are 
stopped. If the MS supports data priority, the MS SNDCP shall inform MLE that the MS default data priority is "not 
applicable" using the MLE-CONFIGURE request primitive. If the MS supports the use of non-conforming PDCHs (see 
clause 18.3.4.9.1), the MS SNDCP should inform MLE that the SNDCP status is "idle" using the MLE-CONFIGURE 
request primitive. 

On reception of an indication that access to the communication resources has become available (on reception of 
MLE-OPEN indication primitive from MLE), if the MS is not temporarily disabled, the MS SNDCP entity shall enter 
IDLE state. If SNDCP is temporarily disabled, the MS SNDCP shall remain in the CLOSED state. 

If SNDCP receives an MLE -ENABLE indication primitive, the MS SNDCP shall record that it is no longer temporarily 
disabled. Then, if SNDCP has previously received an MLE-OPEN indication primitive while in the CLOSED state, the 
MS SNDCP entity shall enter IDLE. If SNDCP has not received an MLE-OPEN indication primitive since it entered the 
CLOSED state, it shall remain in the CLOSED state. 

28.2.4.2 IDLE 

In IDLE state the MS and SwMI shall not have PDP contexts. When entering to state IDLE, the STANDBY, 
RESPONSE_WAIT, READY, and CONTEXT_READY timers are stopped. If the MS supports the use of 
non-conforming PDCHs (see clause 18.3.4.9.1), MLE should be informed that the SNDCP status is "idle" (using the 
MLE-CONFIGURE request primitive). 

Data transfer to and from the mobile subscriber is not possible. The MS is seen as not reachable in this case for TETRA 
Packet data. 

In order to establish SNDCP contexts in the MS and the SwMI, the MS shall perform the PDP context activation 
procedure. After successful PDP context activation the MS shall start STANDBY timer and enter to state STANDBY. 
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On reception of an MLE-BREAK indication primitive from the MLE, the MS SNDCP entity shall enter 
IDLE-Temporary Break state. 

28.2.4.3 IDLE-temporary break 

IDLE-Temporary Break state is only valid for the MS. This state is only entered while access to the communication 
resources has become temporarily unavailable (e.g. due to cell reselection). A temporary break in access to the 
communication resources is signalled to SNDCP by reception of the MLE-BREAK indication primitive from the MLE. 

Network selection and initial cell selection and reselection processes are performed by the MS based on Vh-D 
procedures. The criteria to select a new cell should also contain weight for advanced link support in the cell. 

This state shall be entered from IDLE state on reception of an MLE-BREAK indication primitive. This state shall also 
be entered from STANDBY-Temporary Break state when the STANDBY timer expires. On entering this state from 
STANDBY-Temporary Break, all PDF contexts shall be locally deactivated. 

In IDLE-Temporary Break state the MS and SwMI shall not have PDF contexts. 

Communication between the MS and SwMI SNDCP entities is not possible in this state. 

On reception of an MLE-RESUME indication primitive from the MLE, the MS SNDCP entity shall enter IDLE state. 

28.2.4.4 STANDBY 

In STANDBY state, the subscriber has at least one PDP context activated. 

The MS may receive and respond to SN-PAGE REQUEST PDUs while in this state. 

The MS may initiate activation of a new PDP context while in STANDBY state. 

The MS and SwMI may initiate modification of PDP contexts while in STANDBY state. 

If SNDCP is in the STANDBY state and the MS supports the use of non-conforming PDCHs (see clause 18.4.4.9.1) the 
MS SNDCP should inform the MLE that the SNDCP status is "standing-by" (using the MLE-CONFIGURE request 
primitive) in advance of transmitting an SN-D ATA TRANSMIT REQUEST PDU requesting channel advice (see 
clause 28.2.5a). The MS MLE uses this information to start searching for suitable non-conforming PDCHs. The method 
by which the MS SNDCP gives the MS MLE time to locate a suitable non-conforming PDCH before transmitting a 
SN-D ATA TRANSMIT REQUEST PDU requesting channel advice (see clause 18.3.4.9.11) is outside the scope of the 
present document. 

The MS may initiate deactivation of PDP contexts while in STANDBY state. Before deactivation of the last PDP 
context assigned by the MS to a particular layer 2 logical link, the MS SNDCP entity shall disconnect that logical link 
using the method described in clause 28.3.4.3. After deactivation of the last PDP context the STANDBY timer is 
stopped and SNDCP state is changed to IDLE. 

If the MS SNDCP has previously informed the MLE that the SNDCP status is "standing-by" or "ready" and the MS no 
longer expects to transmit or receive packet data in the forseeable future, the MS SNDCP should inform the MLE that 
its SNDCP status is now "idle" (using the MLE-CONFIGURE request primitive). The MS MLE may use this 
information to stop assessing channel classes and monitoring sectored channels. The information should be sent to the 
MS MLE when SNDCP returns to the IDLE state, but may be sent sooner. 

On reception of a SN-DATA request or SN-UNITDATA request primitive from the service user when the 
SERVICE_CHANGE timer is inactive, the MS SNDCP entity shall transmit a SN-DATA TRANSMIT REQUEST 
PDU. 

During an alternating voice and data communication, an MS SNDCP that has returned from READY to STANDBY 

because of READY timer expiry and now wishes to resume transmitting N-PDUs may transmit 

a SN-DATA TRANSMIT REQUEST PDU if the SERVICE_CHANGE timer is inactive (see clause 28.3.4.2 item e). 

On transmission of a SN-DATA TRANSMIT REQUEST PDU, the MS SNDCP entity shall send an MLE- ACTIVITY 
request primitive with sleep mode set to "stay alive", start the RESPONSE_WAIT timer and enter 
RESPONSE-WAITING state. The STANDBY timer is not stopped on entering RESPONSE- WAITING state. On 
reception (MS only) or transmission (SwMI only) of a SN-ACTIVATE PDP CONTEXT ACCEPT PDU or a 
SN-MODIFY PDP CONTEXT RESPONSE PDU the SNDCP entity shall restart the STANDBY timer. 
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The STANDBY timer is stopped and the SNDCP state is changed to READY on transmission of (SwMI only) or 
reception of (MS only) SN-DATA TRANSMIT REQUEST PDU. Upon moving to the READY state the MS SNDCP 
shall issue an MLE- ACTIVITY request primitive with sleep mode set to "stay alive". If the PDU was individually 
addressed, the MS and SwMI SNDCPs shall each start the READY timer and the MS SNDCP shall, if supported (see 
clause 28.2.6.2), start the CONTEXT_READY timer for the PDP context whose NSAPI was given in the 
SN-DATA TRANSMIT REQUEST PDU. The SwMI SNDCP may also start a CONTEXT_READY timer (see 
clause 28.2.6.2). Where the MS receives a group addressed SN-DATA TRANSMIT REQUEST PDU, on moving to 
READY state the MS shall not start the READY timer or a CONTEXT_READY timer. (The READY timer and the 
CONTEXT_READY timer are not activated when a MS enters READY state for reception of point to multipoint packet 
data) If data priority is supported by both MS and SwMI on the current cell, and the MS SNDCP wishes to make use of 
data priority (see clause 28.3.5.5), the MS SNDCP should inform MLE of the MS default data priority when it enters 
READY state using the MLE-CONFIGURE request primitive. If the MS supports the use of non-conforming PDCHs 
(see clause 18.3.4.9.1), the MS SNDCP should inform MLE that the SNDCP status is "ready" using the 
MLE-CONFIGURE request primitive. If the MS supports the use of D8PSK or QAM channels, it should inform MLE 
of the data class of the NSAPI given in the SN-DATA TRANSMIT REQUEST PDU using the MLE-CONFIGURE 
request primitive. 

On transmission of a SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 1 (i.e. Request accepted), the 
SwMI SNDCP entity shall stop the STANDBY timer, start the READY timer and enter READY state. 

On transmission of a SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = (i.e. Request rejected), the 
SwMI SNDCP entity shall remain in STANDBY state. 

On reception of an SN-UNITDATA PDU, the MS SNDCP shall enter the READY state and, if the PDU was 
individually addressed, shall start the READY timer and, if supported, a CONTEXT_READY timer. (The SwMI 
SNDCP starts READY timer and, if used, the CONTEXT_READY timer on transmission of the PDU.) If the PDU was 
group addressed, the MS SNDCP shall not start the READY timer or a CONTEXT_READY timer on entering the 
READY state. In either case, the MS SNDCP shall issue an MLE- ACTIVITY request primitive with sleep mode set to 
"stay alive". 

During an alternating voice and data communication, an MS that returns from READY to STANDBY because of 
READY timer expiry during the voice call and now wishes to resume the interrupted PDCH communication but has no 
data to send may transmit an SN-RECONNECT PDU with "Data to Send" = and remain in the STANDBY state (see 
clause 28.3.4.2 item e). 

If the STANDBY timer expires, the PDP contexts in the SwMI and in the MS are deleted independently and the 
SNDCP state is changed to IDLE. The SNDCP entity shall issue a SN-NSAPI DEALLOC indication primitive to the 
service user having "Deactivation type" parameter set to value "Deactivate all NSAPIs". If the MS supports the use of 
non-conforming PDCHs, the MS SNDCP informs MLE that the SNDCP status is now "idle" (using the 
MLE-CONFIGURE request primitive). 

Where there is a temporary break in access to the radio communication resources as indicated by the reception of an 
MLE-BREAK indication primitive from the MLE, the MS SNDCP entity shall issue MLE-RELEASE request 
primitives asking MLE to locally disconnect the advanced links and shall enter STANDBY-Temporary Break state. 

If the MS SNDCP entity has an active SERVICE_CHANGE timer and it receives a SN-DATA request or 
SN-UNITDATA request primitive from the service user, it shall delay the transmission of a SN-DATA TRANSMIT 
REQUEST PDU and keep the SN-DATA request or SN-UNITDATA request primitive in its buffers. If the 
SERVICE_CHANGE timer expires, the MS SNDCP entity may continue normal operation and transmit a 
SN-DATA TRANSMIT REQUEST PDU if necessary. 

NOTE: The MS SNDCP entity should handle other service requests normally regardless of active 
SERVICE_CHANGE timer. 

28.2.4.5 STANDBY-temporary break 

STANDBY-Temporary Break state is only valid for the MS. This state is only entered while access to the 
communication resources has become temporarily unavailable (e.g. due to cell reselection). A temporary break in 
access to the communication resources is signalled to SNDCP by reception of the MLE-BREAK indication primitive 
from the MLE. 

Network selection and initial cell selection and reselection processes are performed by the MS based on Vh-D 
procedures. The criteria to select a new cell should also contain weight for advanced link support in the cell. 
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This state shall be entered from STANDBY state and RESPONSE-WAITING state on reception of an 
MLE-BREAK indication primitive. This state shall also be entered from READY -Temporary Break state when the 
READY timer expires. 

Communication between the MS and SwMI SNDCP entities is not possible in this state. 

On reception of an MLE-RESUME indication primitive from the MLE, the MS SNDCP entity shall enter STANDBY 
state. In case the MNI values in the MLE-RESUME indication primitive do not match with ones in the MLE-OPEN 
indication primitive, the MS knows that it has changed the network. Therefore it shall enter the IDLE state and may 
attempt to reactivate the existing PDP contexts by sending SN-ACTIVATE PDP CONTEXT DEMAND PDUs to the 
SwMI after state transition, otherwise all contexts shall be deactivated locally. After successful PDP context activation 
the MS shall start the STANDBY timer and enter to state STANDBY. 

If the STANDBY timer expires, the PDP contexts are deleted locally and the SNDCP state is changed to 
IDLE-Temporary Break. The SNDCP entity shall issue a SN-NSAPI DEALLOC indication primitive to the service user 
having "Deactivation type" parameter set to value "Deactivate all NSAPIs". If the MS supports the use of 
non-conforming PDCHs (see clause 18.3.4.9.1), the MS SNDCP should inform MLE that the SNDCP status is now 
"idle" (using the MLE-CONFIGURE request primitive). 

28.2.4.6 RESPONSE-WAITING 

RESPONSE-WAITING state is only valid for the MS. In RESPONSE-WAITING state, the MS has at least one PDP 
context activated. 

The MS SNDCP entity shall enter RESPONSE-WAITING state from STANDBY state on transmission of a SN-DATA 
TRANSMIT REQUEST PDU. On entering RESPONSE- WAITING state the STANDBY timer remains active and the 
RESPONSE_WAIT timer is started. 

The MS SNDCP entity shall also enter RESPONSE- WAITING state from READY-Temporary Break state on reception 
of an MLE-RESUME indication primitive from the MLE if pending SN-DATA request or SN-UNITDATA request 
primitives from the service user cause the MS to transmit an SN-RECONNECT PDU containing "Data to Send" = 1. In 
this case the MS stops the READY timer and starts the RESPONSE. WAIT and STANDBY timers. 

The MS shall not initiate the activation or modification of PDP contexts while in RESPONSE- WAITING state. The MS 
shall not initiate the deactivation of PDP contexts while in RESPONSE-WAITING state. The MS may respond to a 
SN-PAGE REQUEST while in RESPONSE- WAITING state. 

On reception of a SN-DATA request or SN-UNITDATA request primitive from the service user, the MS SNDCP entity 
shall store the request. If the primitive includes a data priority parameter with higher value than the data priority which 
the MS indicated to MLE with the SN-DATA TRANSMIT REQUEST PDU for which a response is awaited, the 
MS SNDCP may transmit a new SN-DATA TRANSMIT REQUEST PDU including the new data priority in the 
MLE-UNITDATA request primitive. In this case, the RESPONSE-WAIT timer is restarted. 

On reception of a SN-DATA TRANSMIT REQUEST PDU, the MS SNDCP shall stop the STANDBY and 
RESPONSE_WAIT timers, start the READY timer and, if supported, the CONTEXT-READY timer for the indicated 
PDP context, and enter READY state. (The SwMI SNDCP may start a CONTEXT_READY timer on transmission of 
the PDU - see clause 28.2.6.2.) Where the MS receives a group addressed SN-DATA TRANSMIT REQUEST PDU, on 
moving to READY state the MS shall not start the READY timer or a CONTEXT-READY timer. Neither the READY 
timer nor a CONTEXT-READY timer is activated when a MS enters READY state for reception of point to multipoint 
packet data. 

On reception of a SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 1, the MS SNDCP shall stop the 
STANDBY and RESPONSE. WAIT timers, start the READY timer and enter READY state. The MS shall also, if 
supported, start the CONTEXT_READY timer for the PDP context whose NSAPI was given in the 
SN-DATA TRANSMIT RESPONSE PDU. (The SwMI SNDCP may start a CONTEXT_READY timer on 
transmission of this PDU.) 

If data priority is supported by both MS and SwMI on the current cell (see clause 28.3.5.5), the MS SNDCP shall 
inform MLE of the MS default data priority when it enters READY state if it wishes to use data priority, using the 
MLE-CONFIGURE request primitive. 
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If the MS supports the use of non-conforming PDCHs (see clause 18.3.4.9.1), the MS SNDCP should inform the MLE 
that the SNDCP status is "ready" (using the MLE-CONFIGURE request primitive) when it enters the READY state. If 
the MS supports the use of D8PSK or QAM channels, the MS should inform MLE of the data class of the NS API given 
in the SN-DATA TRANSMIT RESPONSE PDU, using the MLE-CONFIGURE request primitive. 

On reception of a SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 0, the MS SNDCP shall: 

send an MLE- ACTIVITY request primitive with sleep mode set to "sleep permitted"; 

stop the RESPONSE_WAIT timer; 



• 



• 



• if the MS SNDCP was awaiting a response to an SN-RECONNECT PDU: issue MLE-RELEASE request 
primitives instructing MLE to locally disconnect the advanced links; 

• enter STANDBY state. 

Where the RESPONSE_WAIT timer expires, the MS SNDCP shall: 

• send an MLE- ACTIVITY request primitive with sleep mode set to "sleep permitted"; 

• if the MS SNDCP was awaiting a response to an SN-RECONNECT PDU: issue MLE-RELEASE request 
primitives instructing MLE to locally disconnect the advanced links; 

• enter STANDBY state. 

Where the STANDBY timer expires, the RESPONSE_WAIT timer is stopped, all PDP contexts are deleted locally and 
the SNDCP state is changed to IDLE. The SNDCP entity shall send an MLE-ACTIVITY request primitive with sleep 
mode set to "sleep permitted", issue a SN-NSAPI DEALLOC indication primitive to the service user having 
"Deactivation type" parameter set to value "Deactivate all NSAPIs". If the MS supports the use of non-conforming 
PDCHs, the MS SNDCP should inform MLE that the SNDCP status is now "idle" (using the 
MLE-CONFIGURE request primitive). 

Where there is a temporary break in access to the radio communication resources as indicated by the reception of an 
MLE-BREAK indication primitive from the MLE, the MS SNDCP entity shall send an MLE-ACTIVITY request 
primitive with sleep mode set to "sleep permitted", stop the RESPONSE_WAJT timer and enter STANDBY-Temporary 
Break state. 

Prior to entering states STANDBY, STANDBY-Temporary Break, CLOSED or IDLE from state 
RESPONSE-WAITING, the MS SNDCP entity shall ensure that all stored SN-DATA request and SN-UNITDATA 
request primitives are deleted. For each SN-DATA request or SN-UNITDATA request primitive deleted, a 
corresponding notification of failure shall be sent to the service user in the form of a SN-DELIVERY indication 
primitive. 

28.2.4.7 READY 

In READY state, the subscriber has at least one PDP context activated. 

The MS may receive and transmit N-PDUs while in this state. 

The MS SNDCP shall enter READY state on reception of a SN-DATA TRANSMIT REQUEST PDU or of 

a SN-DATA TRANSMIT RESPONSE PDU (with Accept/Reject = 1) and the MS SNDCP shall send 

an MLE-ACTIVITY request primitive with sleep mode set to "stay alive". On entering the READY state, the MS 

SNDCP shall stop the RESPONSE_WAIT and STANDBY timers. If the SN-DATA TRANSMIT REQUEST PDU was 

individually addressed (but not if it was group addressed), the MS SNDCP shall start the READY timer and, if 

supported (see clause 28.2.6.2), a CONTEXT_READY timer for the relevant PDP context (i.e. the PDP context whose 

NSAPI was given in the SN-DATA TRANSMIT REQUEST PDU or SN-DATA TRANSMIT RESPONSE PDU). 

The SwMI SNDCP shall enter READY state on transmission of a SN-DATA TRANSMIT RESPONSE PDU (with 
Accept/Reject = 1) or of a SN-DATA TRANSMIT REQUEST PDU. On entering READY state, the 
RESPONSE_WAIT and STANDBY timers are stopped and the READY timer. The SwMI SNDCP may start a 
CONTEXT_READY timer on transmission of the PDU - (see clause 28.2.6.2.). 
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In the case where the MS enters READY state after reception of a group addressed SN-DATA TRANSMIT REQUEST 
PDU, the MS shall not start the READY timer or a CONTEXT_READY timer. Neither the READY timer nor a 
CONTEXT_READ Y timer is activated when a MS enters READY state for reception of point to multipoint packet 
data. 

If data priority is supported by both MS and SwMI on the current cell (see clause 28.3.5.5), the MS SNDCP should 
inform layer 2 of the MS default data priority when it enters READY state if it wishes to use data priority, using the 
MLE-CONFIGURE request primitive. If the MS supports the use of non-conforming PDCHs (see clause 18.3.4.9.1) the 
MS SNDCP should inform MLE that the SNDCP status is "ready" using the MLE-CONFIGURE request primitive. 

The READY timer is re-started when a SN-DATA PDU (point-to-point) is successfully transmitted as indicated by the 
reception of a MLE-REPORT indication primitive and accordingly, the READY timer is re-started when an N-PDU is 
received. The READY timer is also re-started when a SN-UNITDATA (point-to-point) is sent to the MLE for 
transmission in an MLE-UNITDATA request primitive. In the case of reception of point to multipoint N-PDUs, the 
READY timer and CONTEXT-READY timer are not (re)started in the MS. 

In addition the SwMI should have some other mechanisms to optimize the usage of the PDCH. Because the transfer 
delay on the LLC can vary substantially as a function of message length, radio link quality, and other traffic on the 
PDCH, and because only full N-PDUs are delivered to the SNDCP, the READY timer does not provide tight control of 
the stay on the PDCH. 

The SwMI may therefore further refme the state transition handling by using the MLE-RECEIVE indication primitive 
and/or other methods to ensure a timely exit from the READY state (by sending an SN-END OF DATA PDU to the 
MS). The SwMI may use this indication to optimize the length of the stay on the PDCH and should use this indication 
to prevent sending SN-END OF DATA PDU while data reception is in progress on the LLC. The optimal procedures 
for this will depend on SwMI design as well as application behaviour, and is therefore outside the scope of the present 
document. 

If the MS possesses more than one activated PDP context, the MS SNDCP shall maintain a separate 
CONTEXT_READY timer for each activated PDP context. Whenever a SN-DATA PDU or SN-UNITDATA PDU is 
successfully transmitted (as indicated by the reception of a MLE-REPORT indication primitive), whenever a SN-DATA 
PDU is received and whenever an individually addressed SN-UNITDATA PDU is received, the CONTEXT_READY 
timer for the PDP context addressed by the NSAPI in the PDU shall, if supported, be restarted. 

If the MS SNDCP in the READY state receives an SN-DATA request primitive or an SN-UNITDATA request 
primitive referencing a PDP context with an inactive or expired CONTEXT_READY timer, the MS SNDCP entity 
shall, if supported, transmit a SN-DATA TRANSMIT REQUEST PDU. This warns the SwMI to expect an increase in 
data throughput, and gives the SwMI an opportunity to reassign the MS to a more suitable PDCH. If the MS supports 
the D8PSK or QAM modulation mode, the MS SNDCP shall use MLE-CONFIGURE request primitive to inform MLE 
of the most demanding data class of those PDP contexts with active CONTEXT_READY timers and the PDP context 
indicated in the SN-DATA TRANSMIT REQUEST PDU. 

NOTE 1 : The real-time data class is more demanding than the telemetry data class, and the telemetry data class is 
more demanding than the background data class. 

After transmitting an SN-DATA TRANSMIT REQUEST PDU in the READY state, the MS SNDCP shall send an 
MLE-ACTIVITY request primitive with sleep mode set to "stay alive", shall start (or restart) the 

RESPONSE_WAITING timer and remain in the READY state. It shall not transmit any SN-DATA or SN-UNITDATA 
PDUs referencing that N-SAPI until it receives an SN-DATA TRANSMIT RESPONSE PDU referencing that NSAPI 
with Accept/Reject = L 

On receiving an SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 1 referencing a waiting NSAPI, the 
MS SNDCP shall stop the RESPONSE-WAITING timer, shall set up a new advanced link if required, and shall 
commence transmitting SN-DATA PDUs or SN-UNITDATA PDUs for that NSAPI. (The MS SNDCP should support 
the ability to maintain multiple RESPONSE- WAITING timers in the READY state if it supports parallel 
SN-DATA TRANSMIT REQUEST transactions for multiple PDP contexts.) 

On reception of an SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 0, or if the RESPONSE-WAITING 

timer expires, the MS SNDCP shall stop the RESPONSE_WAIT timer and remain in the READY state. The 

MS SNDCP entity shall ensure that all stored SN-DATA request and SN-UNITDATA request primitives relating to the 

relevant PDP context are deleted. For each SN-DATA request and SN-UNITDATA request primitive deleted, a 

corresponding notification of failure shall be sent to the service user in the form of a SN-DELIVERY indication 

primitive. 
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The MS shall not deactivate PDP contexts while in READY state. To initiate the deactivation of one or more PDP 
contexts, a MS must return to STANDBY state. On reception of the SN-NSAPI-DEALLOC request primitive from the 
SNDCP service user, the MS SNDCP entity may attempt to return to STANDBY state prior to the expiry of the 
READY timer by sending a SN-END OF DATA PDU to the SwMI. The SwMI shall respond to the 
SN-END OF DATA PDU with a SN-END OF DATA PDU. 

NOTE 2: If the MS does not get any response to the SN-END OF DATA PDU from the SwMI after a number of 
retransmissions and restarts of READY timer, it may return independently to the STANDBY state even 
before inactivity time-out on assigned SCCH. The number of used retransmissions is an implementation 
dependent issue and is out of the scope of the present document. 

NOTE 3: The MS may also return independently to the STANDBY state without any SN-END OF DATA PDU 
response if the packet data service is overridden by some other service and the channel change to other 
channel is needed to do immediately (e.g. in case of emergency service). However, the MS should then 
send a SN-END OF DATA PDU to the SwMI before the state transition and use the Immediate service 
change information element to indicate that immediate service change has occurred and therefore the MS 
has left the PDCH. 

The MS may initiate activation of a new PDP context while in READY state. The MS may also initiate modification of 
PDP contexts while in this state. Should either happen, the MS shall remain in the state READY. 

Except during cell change or following loss of radio resources, the MS SNDCP remains in the READY state while the 
READY timer is active even when there is no data being communicated. 

When a CONTEXT_READY timer expires and the MS supports the use of D8PSK or QAM channels, the MS SNDCP 
should inform MLE of the most demanding data class of any remaining PDP contexts with active CONTEXT_READY 
timers, using the data class information parameter of MLE-CONFIGURE request primitive. 

If the READY timer expires in the MS when the NS SNDCP is in the READY state, the MS shall send 
SN-END OF DATA PDU to the SwMI and shall restart the READY timer. 

When the READY timer expires in the SwMI, the SwMI shall send SN-END OF DATA PDU to the MS. The SwMI 
shall also send a SN-END OF DATA PDU in response to reception of a SN-END OF DATA PDU from the MS. 

The MS SNDCP shall stop the READY timer, stop all active CONTEXT_READY timers, send an 
MLE-ACTIVITY request primitive with sleep mode set to "sleep permitted", start the STANDBY timer and enter to 
state STANDBY on receiving SN-END OF DATA PDU, unless the SN-END OF DATA PDU is group addressed and 
the READY timer is active. The SwMI SNDCP shall enter to state STANDBY when sending an individually addressed 
SN-END OF DATA PDU. 

In the case where an MS with an active READY timer receives a group addressed SN-END OF DATA PDU, the MS 
shall remain in the READY state with the READY timer still active; if, in this same case, the SN-END OF DATA PDU 
is accompanied by a "channel change response required" parameter set to "true", the MS shall issue an 
MLE-CONFIGURE request primitive containing a "channel change accepted" parameter set to "ignore". 

If the MS supports data priority, the MS SNDCP shall inform MLE that the MS default data priority is "not appUcable" 
when it exits the READY state, using the MLE-CONFIGURE request primitive. The MS should inform MLE that the 
SNDCP status is "standing by" when it exits the READY state if the MS supports the use of non-conforming PDCHs. 

NOTE 4: An active READY timer normally implies that the MS is on the PDCH and involved in point to point 
packet data exchanges. Hence the MS in such a case may not wish to leave the READY state. 

An MS SNDCP that is the READY state with an inactive READY timer (i.e. waiting to receive group addressed 
SN-UNITDATA PDUs) should have a means of returning to the STANDBY state after at least 120 s have elapsed 
without reception of an SN-UNITDATA PDU or an SN-END OF DATA PDU. 

While a SwMI is required by this specification to respond to a SN-END OF DATA PDU received from a MS, by 
sending another SN-END OF DATA PDU to the MS, the SwMI may delay sending the SN-END OF DATA PDU until 
any outstanding data being prepared for transmission on the downlink, has been transmitted if the MS has not indicated 
immediate service change in the SN-END OF DATA PDU. 

NOTE 5: This delay is required due to the MS SNDCP entity having no knowledge of the status of the LLC entity 
i.e. if it is currently receiving advanced link segments from the SwMI. Hence the MS SNDCP entity may 
be unaware that the lower layers are currently receiving packet data. 
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In case the MS indicates the immediate service change in the SN-END OF DATA PDU, the SwMI shall cancel the 
downlink data transmission immediately and enter to state STANDBY. 

NOTE 6: If the immediate service change is indicated by the MS, it does not have to wait for a SN-END OF DATA 
PDU response from the SwMI before entering to state STANDBY. However, the layer 2 
acknowledgement to the SN-END OF DATA PDU sending should be expected before any state 
transition. 

In case the SwMI indicates the immediate service change in the SN-END OF DATA PDU, the MS SNDCP entity 
should stop the READY timer and any CONTEXT_READY timers, start the STANDBY timer and 
SERVICE_CHANGE timer and enter to state STANDBY and, if data priority is supported by the MS, the MS SNDCP 
shall inform MLE that the MS default data priority is "not applicable" using the MLE-CONFIGURE request primitive. 
If the MS supports the use of non-conforming PDCHs, the MS SNDCP should inform the MLE that the SNDCP status 
is "standing-by" (using the MLE-CONFIGURE request primitive) when it exits the READY state. 

NOTE 7: The SwMI should indicate immediate service change only if it is going to send a request to another 

service to the MS which is capable to handle only one active service at the time. When new service is 
accepted in this case, the exact SNDCP functioning is outside the scope of the present document. 

Where there is a temporary break in access to the radio communication resources as indicated by the reception of an 
MLE-BREAK indication primitive from the MLE, the MS SNDCP entity shall enter READY-temporary break state 
and, if data priority is supported by the MS, the MS SNDCP shall inform MLE that the MS default data priority is 
"not applicable" using the MLE-CONFIGURE request primitive. If the MS supports the use of non-conforming 
PDCHs, it shall inform the MLE that the SNDCP status is "standing-by" (using the MLE-CONFIGURE request 
primitive). 

Where there is a failure of the PDCH as indicated by reception of an MLE-CONFIGURE indication primitive from the 
MS MLE indicating "loss of radio resources", the MS SNDCP shall respond as described in clause 8.3.4.7. 

The SwMI SNDCP entity shall stop the READY timer and any CONTEXT_READY timers, start the STANDBY timer 
and enter STANDBY state on reception of the SN-RECONNECT PDU. 

Upon moving to the STANDBY state the MS SNDCP shall send an MLE-ACTIVITY request primitive with sleep 
mode set to "sleep permitted". 

28.2.4.8 READY-temporary break 

READY-Temporary Break state is only valid for the MS. This state shall be entered only from the READY state and 
only when access to the communication resources has become temporarily unavailable (e.g. due to cell reselection or 
loss of radio resource). A temporary break in access to the communication resources is signalled to SNDCP by 
reception of the MLE-BREAK indication primitive or MLE-CONFIGURE indication primitive indicating "loss of radio 
resources" from the MLE. 

Communication between the MS and SwMI SNDCP entities may not be possible in this state. 

While in the READY-temporary break state, the MS SNDCP shall not attempt to transmit SN-DATA or 
SN-UNITDATA PDUs. 

NOTE 1: When the MS SNDCP is in the READY-temporary break state, the MS should suspend transmission of 
N-PDUs, including any partially sent or unacknowledged N-PDUs in the LLC buffers, until the 
MS SNDCP returns to the READY state. 

On reception of an MLE-RESUME indication primitive from the MLE, the MS SNDCP entity shall first check if it has 
a pending SN-DATA request or SN-UNITDATA request primitive. If there is data awaiting transmission, then the MS 
SNDCP entity shall send to the SwMI a SN-RECONNECT PDU with the field "Data to Send" set to 1. 

Where the MS supports advanced link roaming (see clause 28.3.4.4) and where the SNDCP entity is aware that a 
partially transmitted TL-SDU is in the LLC buffers (i.e. one which has not yet been fully transmitted or one for which 
an acknowledgement has not yet been received from the peer entity), then the MS shall also set the field "Data to Send" 

set to 1 . 
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It shall then stop the READY timer and any CONTEXT_READY timers, shall start the STANDBY and 
RESPONSE_WAIT timers and enter RESPONSE-WAITING state. If there is no data awaiting transmission, then MS 
SNDCP entity shall send to the SwMI a SN-RECONNECT PDU with the field "Data to Send" set to 0. It shall then stop 
the READY timer, start the STANDBY timer and enter STANDBY state. 

If the MNI values in the MLE-RESUME indication primitive do not match with the ones in the MLE-OPEN indication 
primitive, the MS knows that it has changed the network and it shall enter the IDLE state. If the MS supports the use of 
non-conforming PDCHs, the MS SNDCP should inform MLE that the SNDCP status is "idle" using the 
ML-CONFIGURE request primitive. The MS shall stop the READY timer and any CONTEXT_READY timers and 
may attempt to reactivate the existing PDP contexts by sending SN-ACTIVATE PDP CONTEXT DEMAND PDUs to 
the SwMI after state transition, otherwise it shall deactivate all contexts locally. After successful PDP context activation 
the MS shall start the STANDBY timer and enter STANDBY state. 

On reception of a SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 1, the MS SNDCP shall stop the 
RESPONSE_WAIT timer, start the READY timer and, if supported, the CONTEXT_READY timer for the indicated 
PDP context and shall enter the READY state. If data priority is supported by both MS and SwMI on the current cell 
(see clause 28.3.5.5), the MS SNDCP should inform MLE of the MS default data priority when it enters the READY 
state if it wishes to use data priority, using the MLE-CONFIGURE request primitive. 

On reception of an SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 0, the MS SNDCP shall send an 
MLE-ACTIVITY request primitive with sleep mode set to "sleep permitted", stop the RESPONSE_WAIT timer, the 
READY timer and any CONTEXT_READY timers, start the STANDBY timer and shall enter the STANDBY state. 

On reception of an SN-DATA TRANSMIT REQUEST PDU, the MS SNDCP shall stop the RESPONSE_WAIT timer, 
start the READY timer and, if supported, the CONTEXT-READY timer for the indicated PDP context, and shall enter 
the READY state. Where the MS receives a group addressed SN-DATA TRANSMIT REQUEST PDU, on moving to 
READY state the MS shall not start the READY timer or a CONTEXT-READY timer. Neither the READY timer nor a 
CONTEXT-READY timer is activated when a MS enters READY state for reception of point to multipoint packet data. 

Where the RESPONSE_WAIT timer expires, the MS SNDCP shall send an MLE-ACTIVITY request primitive with 
sleep mode set to "sleep permitted", start the STANDBY timer, shall stop the READY timer and any 
CONTEXT_READY timers and shall enter the STANDBY state. 

On reception of an MLE-BREAK indication primitive, the MS SNDCP shall stop the RESPONSE_WAIT timer. 

When the READY timer expires, the MS SNDCP entity shall enter STANDBY-Temporary Break state and shall start 
the STANDBY timer. 

NOTE 2: The READY timer does not expire while the RESPONSE_WAIT timer is active. 

Upon moving to the STANDBY, STANDBY-temporary break or IDLE states the MS SNDCP shall send an 
MLE-ACTIVITY request primitive with sleep mode set to "sleep permitted". 



£75/ 



918 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



28.2.5 State transitions and functions 

The movement from one state to the next is dependent on the current state and the triggering event, figures 28.5 and 
28.6 show the state transition diagrams for the MS and SwMI SNDCP entities respectively. 




Figure 28.5: Functional SNDCP State Transition IVIodel for IVIS 
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Last PDP Context Deactivated 
Standby Timer Expires 
Deregistration of MS 




Deregistration of IVIS 



Transmission of 

Pacl<et Data Transmit Request PDU or 
Pacl<et Data Transmit Response PDU 
(witli Accept/Reject set to 'Request 
Accepted by SwIVII'). 



Figure 28.6: Functional SNDCP State Transition lUlodel for SwIUli 
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Tables 28.12 and 28.13 provide a summary of the triggers which shall result in a state transition, the principle actions 
which must be performed and the new state which is entered. 

Table 28.12: MS State Transition Table 



Current State 


Event 


Principle Actions 


New State 


Any State 


MLE-CLOSE indication primitive 
or IVILE-DISABLE indication 
primitive received 


Stop STANDBY, READY, 
CONTEXT READY and 
RESPONSE_WAIT timers. 
Fail all pending SN-DATA and 
SN-UNITDATA request primitives 
Delete all PDP contexts 
If sleep is permitted send 
MLE-ACTIVITY request primitive 
"sleep permitted". 
If MLE-DISABLE received, 
SNDCP records that it is 
temporarily disabled. 


CLOSED 


CLOSED 


MLE-OPEN indication primitive 
received when SNDCP is not 
temporarily disabled. 




IDLE 


IDLE 


MLE-BREAK indication primitive 
received 




IDLE Temp Break 


First PDP Context Activation 


Start STANDBY timer 


STANDBY 


IDLE-Temp Break 


MLE-RESUME indication 
primitive received 




IDLE 


STANDBY 


Last PDP Context Deactivated 


Stop STANDBY timer 


IDLE 


STANDBY timer expires 


Delete all PDP contexts 


IDLE 


Receive SN-DATA TRANSMIT 
REQUEST PDU 


Stop STANDBY timer 
Start READY and 
CONTEXT READY timer 
Send MLE-ACTIVITY request 
primitive "stay alive" 


READY 


Receive SN-DATA or 
SN-UNITDATA request primitive 
and SERVICE_CHANGE timer is 
inactive. 


Transmit SN-DATA TRANSMIT 
REOUEST PDU 
Start RESPONSE WAIT timer 
Send MLE-ACTIVITY request 
primtive "stay alive" 


RESPONSE-WAITING 


SERVICE_CHANGE timer 
expires, and an 

SN-DATA request primitive or an 
SN-UNITDATA request primitive 
is buffered. 


Transmit SN-DATA TRANSMIT 
REOUEST PDU 
Start RESPONSE WAIT timer 
Send MLE-ACTIVITY request 
primitive "stay alive" 


RESPONSE-WAITING 


IVILE-BREAK indication primitive 
received 




STANDBY Temp Break 


STANDBY-temp 
break 


MLE-RESUME indication 
primitive received 




STANDBY 


MLE-RESUME indication primitive 
received and according to MNI values 
the MS has changed the network. 


Stop STANDBY timer 
Delete all PDP contexts 


IDLE 


STANDBY timer expires 


Delete all PDP contexts 


IDLE Temp Break 
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Current State 



Event 



Principle Actions 



New State 



RESPONSE- 
WAITING 



Receive SN-DATA TRANSMIT 
RESPONSE PDU 
(Accept/Reject = 1 ) 



Stop STANDBY timer 
Stop RESPONSE_WAIT timer 
Start READY and 
CONTEXT READY timer 



READY 



Receive SN-DATA TRANSIVIIT 
RESPONSE PDU 
(Accept/Reject = 0) 



Stop RESPONSE_WAIT timer 
Send MLE-ACTIVITY request 
primitive "sleep permitted" 
Fail all pending SN-DATA and 
SN-UNITDATA request primitives 



STANDBY 



Receive SN-DATA TRANSIVIIT 
REQUEST PDU 



RESPONSE_WAIT timer expires 



Stop STANDBY timer 
Stop RESPONSE_WAIT timer 
Start READY and 
CONTEXT_READY timer 

Fail all pending SN-DATA and 
SN-UNITDATA request primitives 
Send MLE-ACTIVITY request 
primitive " sleep permitted " 



READY 



STANDBY 



STANDBY timer expires 



Stop RESPONSE_WAIT timer 
Send MLE-ACTIVITY request 
primitive " sleep permitted " 
Fail all pending SN-DATA and 
SN-UNITDATA request primitives 
Delete all PDP contexts 



IDLE 



MLE-BREAK indication primitive 
received 



Stop RESPONSE_WAIT timer 
Fail all pending SN-DATA or 
SN-UNITDATA request primitives 
Send MLE-ACTIVITY request 
primitive "sleep permitted" 



STANDBY temp break 



READY 



Receive SN-END OF DATA PDU 



Stop READY timer 
Start STANDBY timer 
Send MLE-ACTIVITY request 
primitive "sleep permitted" 



STANDBY 



Number of SN-END OF DATA 
PDU retransmissions exceeded 



Stop READY timer 
Start STANDBY timer 
Send MLE-ACTIVITY request 
primitive "sleep permitted" 



STANDBY 



Immediate service change 
indicated 



Stop READY timer 
Stop CONTEXT_READY timers 
Send MLE-ACTIVITY request 
primitive "sleep permitted" 
Start STANDBY timer 



STANDBY 



MLE-BREAK indication primitive 
received 



READY temp break 



MLE-CONFIGURE indication 
primitive received (loss of radio 
resources) and there is data to 
send 



Transmit SN-RECONNECT PDU 

(Data to Send = 1) 

Start RESPONSE WAIT timer 



READY Temp Break 



MLE-CONFIGURE indication 
primitive received (loss of radio 
resources) and there is no data to 
send 



Transmit SN-RECONNECT PDU 

(Data to Send = 0) 

Send MLE-ACTIVITY request 

primitive "sleep permitted" 

Stop READY timer 

Start STANDBY timer 



STANDBY 
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Current State 


Event 


Principle Actions 


New State 


READY-temp 


MLE-RESUME indication 


Transmit SN-RECONNECT PDU 


RESPONSE-WAITING 


break 


primitive received and tliere is 


(Data to Send = 1) 






data to send. 


Stop READY timer 

Stop CONTEXT READY timers 

Start STANDBY timer 

Start RESPONSE_WAIT timer 




IVILE-RESUIVIE indication 


Transmit SN-RECONNECT PDU 


STANDBY 




primitive received and tliere is no 


(Data to Send = 0) 






data to send. 


Send MLE-ACTIVITY req "sleep 

permitted" 

Stop READY timer 

Stop CONTEXT READY timers 

Start STANDBY timer 




IVILE-RESUME indication 


Stop READY timer 


IDLE 




primitive received and according 


Stop CONTEXT READY timers 






to IVINI values the MS has 


Delete all PDP contexts 






changed the network. PDP 


Send MLE-ACTIVITY request 






context activation after migration. 


primitive "sleep permitted" 




Receive SN-DATA TRANSMIT 


Stop RESPONSE WAIT timer 


READY 




RESPONSE PDU 


Start READY timer 






(Accept/Reject = 1 ) 






Receive SN-DATA TRANSMIT 


Stop RESPONSE WAIT timer 


STANDBY 




RESPONSE PDU 


Stop READY timer 






(Accept/Reject = 0) 


Send MLE-ACTIVITY request 
primitive "sleep permitted" 
Fail all pending SN-DATA req 




Receive SN-DATA TRANSMIT 


Stop RESPONSE WAIT timer 


READY 




REOUEST PDU 


Start READY timer 




RESPONSE_WAIT timer expires 


Fail all pending SN-DATA request 


STANDBY 






primitives 








Send MLE-ACTIVITY request 








primitive "sleep permitted " 








Stop READY timer 








Start STANDBY timer 




READY timer expires 


Send MLE-ACTIVITY request 


STANDBY Temp Break 






primitive "sleep permitted" 








Start STANDBY timer 
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Table 28.13: SwMI State Transition table 



Current State 


Event 


Principle Actions 


New State 


IDLE 


First PDP Context Activation 


Start STANDBY timer 


STANDBY 


STANDBY 


Last PDP Context Deactivated 


Stop STANDBY timer 


IDLE 


STANDBY timer expires 


Delete all PDP contexts 


IDLE 


Deregistration of IVIS 


Delete all PDP contexts 


IDLE 


Receive SN-DATA or SN-UNITDATA 
request primitive 


Transmit SN-DATA 

TRANSMIT REQUEST 

PDU 

Stop STANDBY timer 

Start READY timer and 

CONTEXT_READY timer 


READY 


Receive SN-DATA TRANSMIT 
REQUEST PDU 


Transmit SN-DATA 
TRANSMIT RESPONSE 
PDU (Accept/Reject = 1) 
Stop STANDBY timer 
Start READY timer and 
CONTEXT_READY timer 


READY 


READY 


READY timer expires 


Transmit SN-END OF 

DATA PDU 

Stop READY timer 

Start STANDBY timer and 

CONTEXT_READY timer 


STANDBY 


SN-END OF DATA PDU received without 
indication of immediate service change, 
and SwIVII not transmitting TL-SDU to 
MS. 


Transmit SN-END OF 
DATA PDU 

Stop READY timer and 
CONTEXT READY timers 
Start STANDBY timer 


STANDBY 


Deregistration of MS 


Stop READY timer and 
CONTEXT_READY timers 
Delete all PDP contexts 


IDLE 


SN-END OF DATA PDU received with an 
indication of immediate service change 


Stop READY timer and 
CONTEXT READY timers 
Start STANDBY timer 


STANDBY 


SN-RECONNECT PDU received 


Stop READY timer 
Start STANDBY timer 


STANDBY 



28.2.5a MLE-UNITDATA request primitive 



If the MS supports the use of non-conforming PDCHs and the MS SNDCP is transmitting an 

SN-DATA TRANSMIT REQUEST, an SN-P AGE-RESPONSE or an SN-RECONNECT PDU, the MS SNDCP should 
set the channel advice flag in the MLE-UNITDATA request primitive containing the PDU to "channel advice 
requested". For all other PDUs, the MS SNDCP shall set the channel advice flag in the MLE-UNITDATA request 
primitive to "channel advice not requested". 
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28.2.5b other MLE primitives 



This clause describes other MLE primitives at the LTPD-SAP which are more or less separate from normal SNDCP 
state transition model. 

On reception of an MLE-INFO indication primitive, which indicates that the subscriber class being broadcasted by the 
SwMI and the subscriber class of the MS do not match in the current cell, the MS SNDCP shall stop the communication 
with the peer entity totally. However, the SwMI should not offer packet data service to the MS, which subscriber class 
parameter does not match. This information is relevant also in other SNDCP states where the MS is seen as reachable in 
this case for TETRA Packet data. 

On reception of an MLE-BUS Y indication primitive, the MS SNDCP entity knows that an MM protocol exchange is in 
progress. Then the MS SNDCP shall stop the communication with the peer entity and cannot continue it until it receives 
an MLE-IDLE indication primitive. 

On reception of an MLE-IDLE indication primitive, the MS SNDCP entity knows that an MM protocol exchange has 
completed and it may continue its normal function. 

On reception of an MLE-CLOSED indication primitive, the MS SNDCP shall enter the CLOSED state. 

On reception of an MLE-DIS ABLE indication primitive, the MS SNDCP shall record that the MS is now temporarily 
disabled and shall enter the CLOSED state. SNDCP shall remain temporarily disabled through power cycles and 
through cycles of loss and gain of radio resources until it receives an MLE-ENABLE indication primitive from MLE. 

28.2.6 STANDBY, READY, CONTEXT_READY and RESPONSE_WAIT 
timer functions 

28.2.6.1 STANDBY timer function 

The purpose of the STANDBY Timer is to work as a fallback timer to delete the PDP contexts when they remain 
unintentionally undeleted. 

The STANDBY timer function maintains the STANDBY timer in the MS and SwMI. When the STANDBY timer 
expires, the MS and SwMI return to IDLE state (or for the MS only, where the previous state was 
STANDBY-Temporary Break, then the MS shall enter IDLE-Temporary Break), and the PDP contexts are deleted 
locally. 

The duration of the STANDBY timer is the same in the MS and SwMI. Normally, the length of the STANDBY timer is 
defined by a default value. The SwMI, and only the SwMI, may change this value dynamically by transmitting a new 
value in the header part of a PDP context activation PDU (accept). 

In the present document, the STANDBY timer shall not be set to 0. If the STANDBY timer is set to all Is (binary), then 
the STANDBY timer function is deactivated (i.e., the timer no longer runs and the MS and SwMI remain in STANDBY 
state). 

The STANDBY timer is reset and begins running in the MS in the following circumstances: 

on entering STANDBY state from IDLE state; 

on entering STANDBY state from RESPONSE- WAITING state after reception of a SN-DATA TRANSMIT 
RESPONSE PDU with Accept/Reject = 0; 

on entering STANDBY state from READY state after reception of a SN-END OF DATA PDU; 

on entering STANDBY state from READY-Temporary Break state after transmission of a SN-RECONNECT 
PDU with "Data to Send" = ; 

on entering RESPONSE-WAITING state from READY-Temporary Break state after transmission of a 
SN-RECONNECT PDU with "Data to Send" = 1 ; 

on entering STANDBY-Temporary break state from READY-Temporary Break state. 
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The STANDBY timer is stopped in the MS in the following circumstances: 

• On entering CLOSED state; 

• On entering IDLE state from STANDBY state; 

• On entering READY state from STANDBY state after reception of a SN-DATA TRANSMIT REQUEST 
PDU; 

• On entering READY state from RESPONSE-WAITING state after reception of a SN-DATA TRANSMIT 
REQUEST PDU; 

• On entering READY state from RESPONSE-WAITING state after reception of a SN-DATA TRANSMIT 
RESPONSE PDU with Accept/Reject = L 

The STANDBY timer is reset and begins running in the SwMI in the following circumstances: 

• on entering STANDBY state from IDLE state; 

• after transmission of a SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 0; 

• on entering STANDBY state from READY state after transmission of a SN-END OF DATA PDU; 

• on entering STANDBY state from READY state after reception of a SN-RECONNECT PDU. 
The STANDBY timer is stopped in the SwMI in the following circumstances: 

• on entering IDLE state from STANDBY state; 

• on entering READY state from STANDBY state after transmission of a SN-DATA TRANSMIT REQUEST 
PDU; 

• on entering READY state from STANDBY state after transmission of a SN-DATA TRANSMIT RESPONSE 
PDU with Accept/Reject = L 

28.2.6.2 READY timer and CONTEXT_READY timer functions 

The READY timer function maintains the READY timer in the MS and SwMI. The READY timer may be defined for 
each MS separately. The READY timer controls, with the help of other potential timers, the time an MS and SwMI 
remains in READY state after either a SN-DATA, SN-UNITDATA, SN-DATA TRANSMIT REQUEST PDU (SwMI 
to MS) or SN-DATA TRANSMIT RESPONSE PDU (SwMI to MS) has been transmitted between the MS and SwMI. 
When the READY timer expires in the MS, the MS shall send SN-END OF DATA PDU to the SwMI and restart 
READY timer. The MS shall stop the READY timer, start the STANDBY timer and enter to the STANDBY state on 
receiving SN-END OF DATA PDU. When the READY timer expires in the SwMI, the SwMI shall send a SN-END OF 
DATA PDU to the MS and enter to the STANDBY state. The SwMI may also send a SN-END OF DATA PDU to the 
MS for its own reasons. 

NOTE 1: It is recommended that Packet Data CHannel (PDCH) releasing is done by the SwMI and the MS PDCH 
release is used as a fallback method. This means that the SwMI should set its own READY timer to a 
shorter value than the one sent to the MS in the SN- ACTIVATE PDP CONTEXT ACCEPT PDU. 

In the present document, the READY timer shall not be set to 0. 

The READY timer is reset and begins running in the MS and SwMI in the following cases: 

• every time an SN-DATA PDU has been transmitted successfully (as indicated by reception of a 
MLE-REPORT indication primitive from the MLE) or received by the MS or SwMI; 

• every time an SN-UNITDATA PDU is sent to the MLE in an MLE-UNITDATA request primitive; 

• when a SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = 1 is transmitted (SwMI only) or 
received (MS only); 

• when a SN-DATA TRANSMIT REQUEST PDU is transmitted (SwMI only) or received (MS only); 
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• when an MLE-CONNECT confirm or an MLE-CONNECT indication primitive is received from the MLE; 
and 

• when an MLE-RECONNECT confirm or an MLE-RECONNECT indication primitive is received from the 
MLE. 

NOTE 2: In the case where a MS receives a group addressed SN-DATA TRANSMIT REQUEST the MS SNDCP 
entity does not start the READY timer when entering READY state. The READY timer is not activated 
when a MS enters READY state for reception of point to multipoint packet data. 

NOTE 3: In the case of the SN-DATA TRANSMIT RESPONSE and SN-DATA TRANSMIT REQUEST PDUs, 
transmitted here means that it has been transmitted over the air interface. Acknowledgement from the 
peer entity is not required nor awaited. 

The READY timer should not expire while the MS is actively transmitting an N-PDU at layer 2. The READY timer 
shall not expire while the RESPONSE. WAIT timer or any CONTEXT_READY timer is active. 

NOTE 4: If the READY time runs out while the MS is actively transmitting an N-PDU at layer 2 or while any 
CONTEXT_READY timer is active, the READY timer should not announce the timer expiry event to 
SNDCP until the MS has finished transmitting an N-PDU at layer 2 and the RESPONSE_WAIT timer 
and the last CONTEXT_READY timer has expired. The READY timer should not announce the expiry 
event at all if the READY timer is reset before it has announced the expiry event. 

The CONTEXT_READY timer function allows the MS SNDCP to advise the SwMI when the MS is in the READY 
state, but wishes to start transmitting N-PDUs for a quiescent PDP context. (A quiescent PDP context is one which has 
not transmitted or received N-PDUs since it was activated, or for a period of time greater than the duration of its 
CONTEXT_READY timer). This gives the SwMI an opportunity to adjust the radio resources available to the MS to 
suit the MS's total QoS requirement. 

MSs which support the transmission or reception of data through more than one PDP context at the same time shall 
support the use of CONTEXT_READY timers. 

A SwMI that supports the use of QoS negotiation during PDP context activation may make local use of 
CONTEXT_READY timers to track the state of the MS's CONTEXT_READY timers. A SwMI that uses 
CONTEXT_READY timers shall follow the same rules as the MS for management of the READY timer and the 
CONTEXT_READY timers. 

The SNDCP service user may propose a CONTEXT_READY timer value to the MS SNDCP in the 

NSAPI-QoS negotiation parameter of the SN-NSAPI ALLOC request and SN-NSAPI MODIFY request primitives. The 

MS should then propose this CONTEXT_READY timer value to the SwMI in the QoS information element during PDP 

context activation or modification, if QoS negotiation is supported by the MS and the current cell (SwMI support for 

QoS negotiation is indicated in the MLE-INFO indication primitive). If no value was specified in the 

SN-NSAPI ALLOC or SN-NSAPI MODIFY request primitive, and QoS negotiation is supported by the MS and the 

current cell, or if the MS does not support the use of CONTEXT_READY timers, the MS SNDCP should propose to 

the SwMI that the value of the CONTEXT_READY timer should be set to track the READY timer value. 

If the MS proposes that the CONTEXT_READY timer shall track the READY timer value, the SwMI shall accept that 
proposal. If the MS proposes a CONTEXT_READY timer that does not track the READY timer value and the SwMI 
uses CONTEXT_READY timers, the SwMI may accept the proposal (possibly with a modified time period). If the MS 
proposes a CONTEXT_READY timer that is longer than the READY timer and the SwMI does not use 
CONTEXT_READY timers, the SwMI shall propose a CONTEXT_READY timer that is less than or equal to the 
READY timer or that shall track the READY timer. 

The CONTEXT_READY timers shall obtain their values either from the QoS information element of the 
SN-ACTIVATE PDP CONTEXT ACCEPT and SN-MODIFY PDP CONTEXT RESPONSE PDUs for the relevant 
PDP context, if included, or shall track the value of the READY timer if the QoS information element was not included. 

If a CONTEXT_READY timer is set to track the READY timer value, it shall be set to the READY timer value 
included in the SN-ACTIVATE-PDP-CONTEXT ACCEPT PDU most recently sent to that MS (irrespective of the 
NSAPI in the PDU) each time it is restarted. 

NOTE 5: A PDP context to be used for transmission or reception of intermittent data (such as for telemetry class 
data) may benefit from using a longer CONTEXT_READY timer than would be required by a PDP 
context used for background class data. 
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The CONTEXT_READY timer, if supported, shall be started or re-started whenever an SN-DATA, 
SN-DATA TRANSMIT REQUEST PDU (SwMI to MS only) or SN-DATA TRANSMIT RESPONSE PDU 
(with Accept/Reject = 1) for that PDP context has been transmitted successfully (as indicated by MLE-REPORT 
indication primitive) or has been received for a non-group address, or when an SN-UNITDATA PDU has been sent to 
MLE for transmission. The CONTEXT_READY timer shall not be started or re-started by group-addessed PDUs. 

If SNDCP is in the READY state, but a CONTEXT-READY timer is inactive or has expired when the MS SNDCP 
receives an SN-DATA request or SN-UNITDATA request primitive for that PDP context, the MS SNDCP shall 
transmit an SN-DATA TRANSMIT REQUEST PDU to the SwMI as an indication that its immediate QoS requirement 
has changed, start the RESPONSE_WAIT timer and wait for an SN-DATA TRANSMIT RESPONSE PDU (with 
Accept/Reject = 1) for the relevant PDP context before transmitting an SN-DATA PDU or SN-UNITDATA PDU for 
that PDP context. 

If the MS SNDCP is in the READY state when it receives an SN-NS API MODIFY request primitive from the 
MS SNDCP service user requesting the PDP context to be paused, the MS SNDCP shall stop the CONTEXT_READY 
timer and, if the current cell supports QoS negotiation during PDP context activation, shall notify the SwMI SNDCP 
that it is pausing use of the PDP context by transmitting an SN-MODIFY PDP CONTEXT USAGE PDU. The SwMI 
shall stop any CONTEXT_READY timer for the relevant PDP context when it receives this notification. 

All CONTEXT_READY timers shall be stopped when SNDCP exits the READY state or the MS SNDCP exits the 
READY temporary break state into some state other than these. 

28.2.6.3 RESPONSE_WAIT Timer Function 

The RESPONSE_WAIT timer function maintains the RESPONSE_WAIT timer in the MS. The duration of the 
RESPONSE_WAIT timer is assigned by the SwMI at PDP context activation. The value received from the SwMI in the 
most recent PDP context activation shall apply to all PDP contexts. The RESPONSE_WAIT timer controls the time an 
MS shall await a response from the SwMI to a SN-DATA TRANSMIT REQUEST or SN-RECONNECT PDU and 
hence the time the MS SNDCP remains in RESPONSE-WAITING state. If a response (in the form of a SN-DATA 
TRANSMIT RESPONSE) is received before the RESPONSE. WAIT timer expires, then the MS SNDCP shall leave 
RESPONSE- WAITING state (if it is in that state) and shall stop the RESPONSE_WAIT timer. If the MS is in the 
RESPONSE. WAITING or READY temporary break state when the RESPONSE_WAIT timer expires before a 
response is received, then the MS shall go to the STANDBY state. If the MS is in the READY state when the response 
is received or when the RESPONSE_WAIT timer expires, it shall remain in the READY state (this can occur when the 
MS is attemping to transmit N-PDUs for a quiescent PDP context when busy transmitting or receiving N-PDUs for a 
different PDP context). 

The RESPONSE. WAIT timer is reset and begins running in the MS when entering RESPONSE- WAITING state. 

The RESPONSE. WAIT timer is stopped in the MS when leaving RESPONSE- WAITING state. 

NOTE: The MS SNDCP may support concurrent RESPONSE_WAIT timers (one per PDP context) in the 
READY state. 

28.2.6.4 SERVICE_CHANGE Timer Function 

The SERVICE_CHANGE timer shall be started by the MS SNDCP when it receives an individually addressed 
SN-END OF DATA PDU indicating immediate service change. The MS shall then enter the STANDBY state. While 
the SERVICE_CHANGE timer remains active the MS shall defer sending the SwMI an SN-DATA TRANSMIT 
REQUEST PDU (in respect of any pending N-PDUs). 

When the SERVICE_CHANGE timer expires, if the MS SNDCP has any pending N-PDUs it shall send the SwMI an 
SN-DATA TRANSMIT REQUEST PDU in the normal way, preparatory to sending the pending N-PDUs. 

The SERVICE_CHANGE timer function enables the SwMI to keep the MS SNDCP in the STANDBY state on the 
MCCH for the SERVICE_CHANGE period of time, even though the MS SNDCP may have pending N-PDUs ready for 
transmission. This allows the SwMI to complete an exchange of signalling with the MS on the MCCH concerning some 
other service. 
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28.3 SNDCP Procedures 

28.3.1 Services provided by tine protocol 

SNDCP performs the following functions (see figures 28.7 and 28.8): 

• PDP context activation and PDP context deactivation; 

• assignment of layer 2 logical links to activated PDP contexts; 

• Packet Data CHannel (PDCH) handling; 

• multiplexing of N-PDUs from one or several higher protocol entities onto one or more layer 2 connections; 

• mapping of SN primitives received from the network layer into corresponding MLE-UNITDATA request 
primitives to be passed to the MLE; 

• if data priority is not supported by the MS, management of the delivery sequence according to the PDU 
priority of SN-UNITDATA and SN-DATA request primitives; 

• if data priority is supported by the MS: 

management of the delivery sequence according to the PDU priority and data priority of 
SN-UNITDATA and SN-DATA request primitives; 

management of the data priority of N-PDUs. 

• compression and recovery of redundant protocol control information (e.g. TCP/IP header). Header 
compression is performed independently for each NSAPI; 

• compression and recovery of redundant user data. Data compression is performed independently for each 
NSAPI; 

• management of application-level QoS requirements. 
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MEX (optional) 

Parameters: 

- NSAPI 

- PDU priority (optional) 

- data priority (optional) 

- data importance (optional) 

- schedule surplus flag (optional) 
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Figure 28.7: SNDCP model for transmitting end 
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28.3.2 Underlying services assumed by tine protocol 

The following services are expected to be provided by the MLE through the LTPD-SAP: 

• acknowledged (MS - > SwMI and SwMI- > MS) and unacknowledged (MS -> SwMI and SwMI - > MS) data 
transfer; point-to-point (MS - > SwMI and SwMI - > MS) and point-to-multipoint data transfer (SwMI - > 
MS); 

• high reliability data transfer (PCS on, acknowledged), moderate reliability data transfer (PCS off, 
acknowledged) and low delay (low reliability) data transfer (PCS on or off and unacknowledged); 

• PDU priority based transfer of SN-PDUs (eight PDU priority levels); 

• if the MS does not support data priority: 

in-order delivery of SN-PDUs per PDU priority (i.e. SN-PDUs with the same PDU priority have to 
appear at the receiving end in the same order as transmitted between SNDCP entities). This is required 
only for acknowledged service; 

• if the MS does support data priority: 

data-priority based N-PDU access to radio resources (8 data priority levels); 

in-order delivery of SN-PDUs not containing an N-PDU per PDU priority (i.e. SN-PDUs not containing 
an N-PDU and having the same PDU priority have to appear at the receiving end in the same order as 
transmitted between SNDCP entities). This is required only for acknowledged service; 

in-order delivery of SN-DATA PDUs per PDU priority and data priority (i.e. SN-DATA PDUs with the 
same PDU priority and data priority have to appear at the receiving end in the same order as transmitted 
between SNDCP entities); 

in-order transmission of SN-UNITDATA PDUs per PDU priority and data priority (i.e. SN-UNITDATA 
PDUs with the same PDU priority and data priority have to be transmitted a first time in the same order 
as sent to MLE by the MS SNDCP); 

support for variable length SN-PDUs; 

indications about radio link condition (CLOSE, OPEN, BREAK); 

indications about LLC connections (establishment, re-connection, release); 

access to disconnect LLC connections; 

support for regularly scheduled slot grants (scheduled access), including provision of schedule timing 
indications to the MS SNDCP. 
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28.3.3 Context activation, modification and deactivation procedures 

An MS in IDLE, STANDBY or READY states can initiate PDF context activation functions to establish a virtual data 
channel i.e. PDF context between the MS and the SwMI. An MS in STANDBY state can initiate PDF context 
deactivation functions. An MS or SwMI in the STANDBY or READY states can initiate PDF context modification. 

Upon receiving an SN-ACTIVATE PDF CONTEXT DEMAND FDU, the SwMI shall initiate procedures to set up the 
PDF context. 

Upon receiving an SN-MODIFY PDF CONTEXT REQUEST FDU, the SwMI shall, if supported, initiate procedures to 
modify the PDF context. 

Upon receiving an SN-MODIFY PDF CONTEXT REQUEST FDU, the MS shall, if supported, confirm to the SwMI 
the modification of the PDF context and advise affected applications. 

Upon receiving a SN-DEACTIVATE PDF CONTEXT DEMAND FDU, the SwMI shall initiate procedures to delete 
the PDF context. 

Upon receiving a SN-DEACTIVATE PDF CONTEXT DEMAND FDU, the MS shall initiate procedures to delete the 
PDF context. 

A MS may only attempt to activate one PDF context at a time. Hence a MS after transmitting a 

SN-ACTIVATE PDF CONTEXT DEMAND FDU must await the occurrence of one of the following events, before 

sending a new SN-ACTIVATE PDF CONTEXT DEMAND FDU: 

• reception of a SN-ACTIVATE PDF CONTEXT ACCEPT FDU; 

• reception of a SN-ACTIVATE PDF CONTEXT REJECT FDU; 

• expiration of the FDF_ACTIVATE_WAIT timer. 

A MS may only have one PDF context modification request outstanding at a time. Hence a MS, after transmitting a 
SN-MODIFY PDF CONTEXT REQUEST FDU must await the occurrence of one of the following events before 
sending a new SN-MODIFY PDF CONTEXT REQUEST FDU: 

• reception of a SN-MODIFY PDF CONTEXT RESPONSE FDU with modify type = response; 

• expiration of the FDP_MODIFY_WAIT timer. 

A MS may only have one PDF context deactivation request outstanding at a time. Hence a MS after transmitting a 
SN-DEACTIVATE PDF CONTEXT DEMAND FDU must await the occurrence of one of the following events, before 
sending a new SN-DEACTIVATE PDF CONTEXT DEMAND FDU: 

• reception of a SN-DEACTIVATE PDF CONTEXT ACCEPT FDU; 

• expiration of the PDP_DEACTIVATE_WAIT timer. 

An MS shall activate a primary PDF context before it attempts to activate a secondary PDF context linked to that 
primary PDF context. Primary and secondary PDF context activation requests are indicated by the "address type 
identifier in demand" information element. 

When a primary PDF context is deactivated, all secondary PDF contexts linked to that primary PDF context shall be 
locally deactivated. 

The SwMI shall not accept a primary PDF context activation request specifying a PDF address already in use by some 
other PDF context. 

A SwMI that supports QoS negotiation during PDF context activation but does not support the use of secondary PDF 
contexts shall refuse an MS's request for activation of a secondary PDF context with reject cause "Secondary PDF 
contexts not supported". 

The MS shall not include the QoS information element in its response to an SN-MODIFY PDF CONTEXT REQUEST 
FDU received from the SwMI. 
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If the MS includes a QoS information element in a PDP context activation or modification request and the SwMI 
accepts the activation or modification request but includes no QoS information element in its response, the MS shall 
assume that the requested QoS has been granted by the SwMI. If the SwMI includes a QoS information element in its 
reply to the MS, the MS shall assume that those QoS items included in the reply replace the corresponding items 
proposed by the MS, whereas any items omitted by the SwMI remain as proposed by the MS. 

If the MS requests use or modification of scheduled access and the SwMI is unable to provide the proposed schedule, 
the SwMI shall respond with an SN-ACTIVATE-PDP CONTEXT REJECT PDU or an 
SN-MODIFY PDP CONTEXT RESPONSE PDU indicating "modification rejected". 

The MS shall not include a QoS filter specification in the QoS element of any PDU relating to a primary PDP context. 
The SwMI shall reject any PDP context activation or modification request for a primary PDP context that includes a 
QoS filter specification, using reject cause "QoS filter not available for primary PDP context". See clause 28.3.9 for a 
description of QoS filters. 

28.3.3.1 Internet Protocol addressing support 

28.3.3.1 .1 IPv4 - Static and dynamic IP addresses 

A TETRA system can be viewed as a single or multiple IP subnets. A TE which is attached to a MT on a TETRA 
network, can be viewed as a host on an IP subnet. 

In order for IP packets from an external IP network, to reach a data TE which is attached to a MT on a TETRA network, 
it is necessary for the destination address used in the IP packets to be topologically correct i.e. packets, using standard 
internet routing procedures, can be forwarded to the TETRA network. The forwarding of packets within the TETRA 
network is outside of the scope of the present document. 

IP addresses can be allocated to an MS in two different ways: 

• an IP address is assigned permanently to the MS. The IP address shall be sent to the SwMI when activating 
PDP context; 

• the SwMI assigns a dynamic IP address to the MS when PDP context is activated. 
It is the operator that defines in the subscription whether a dynamic IP address can be used. 

When dynamic addressing is used, it is the responsibility of the SwMI to allocate and release the dynamic IP address. 

28.3.3.1.2 Mobile IPv4 

Mobile IP allows nodes to move from one IP subnet to another without changing their IP address. A brief overview of 
Mobile IP is given below so as to help illustrate the addressing concept, however the reader is referred to 
RFC 3344 [39] for a more complete description of the protocol. 

In the description below, the following definitions apply: 

• Mobile Node: An IP host or router that changes its point of attachment to the internet from one subnet to 
another; 

• Home address: Internet protocol address, that is assigned to a Mobile Node for an extended period of time. 
This address is used by all other nodes when attempting to send IP packets to the Mobile Node. This address 
remains constant irrespective of the Mobile Nodes point of attachment to the internet; 

• Home network: A network, having a network prefix matching that of the Mobile Node's home address. 
Standard IP routing mechanisms ensure that IP packets destined for the Mobile Node's home address are 
routed via the Mobile Node's home network; 

• Foreign network: Any network, other than the Mobile Node's home network, i.e. a network which has a 
network prefix different to that of the Mobile Node's home IP address; 

• Visited Network: A foreign network to which the Mobile Node is currently connected; 
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Home Agent: A router on a Mobile Node's home network which tunnels IP packets for delivery to the Mobile 
Node when it is away from its home network. The Home Agent has similar functionality to the Home Location 
Register (HLR) in GSM; 

Foreign Agent: A router on the Mobile Node's visited network which detunnels and delivers IP packets to the 
Mobile Node, that were tunnelled by the Home Agent; 

Care-of Address: The termination point of a tunnel towards a Mobile Node, for IP packets forwarded to the 
Mobile Node while it is away from its home network. The protocol can use two different types of care-of 
address: a "foreign agent care-of address" is an address of a foreign agent with which the mobile node is 
registered, and a "co-located care-of address" is an externally obtained local address which the mobile node 
has associated with one of its own network interfaces. 

A Mobile Node is given a long term IP address on a home network. This IP address is administered in the same way as 
a "permanent" IP address is provided to a stationary host. When the Mobile Node detects that it is located on its home 
network, it operates without mobility services. 

When a Mobile Node detects that it has moved to a foreign network, it obtains a care-of address on the foreign network. 
The mobile node then registers its new care-of address with its Home Agent. 

IP packets sent to the Mobile Node's home address are intercepted by its Home Agent, tunnelled by the Home Agent to 
the Mobile Node's care-of address, received at the tunnel endpoint (typically the foreign agent), and finally delivered to 
the mobile node. 

In the reverse direction, IP packets sent by the mobile node are generally delivered to their destination using standard IP 
routing mechanisms, not necessarily passing through the home agent. 

The TETRA packet data specification extends a TETRA network to act as one or more IP subnets. A TETRA network 
may offer Mobile IP services by including Home Agent and/or Foreign Agent functionality. The TETRA packet data 
specification provides a mechanism by which a Mobile Node may use Mobile IP services where they are available. 

As an example, where a TETRA SwMI includes Mobile IP Foreign Agent functionality, a Mobile Node may perform 
Mobile IP Registration as described in IETF RFC 3344 [39] with its Home Agent (which may be located on a fixed IP 
subnet) via the SwMI based Foreign Agent. This Foreign Agent shall then act as the tunnel end point for those IP 
packets forwarded by the Home Agent. The Mobile Node may learn the Foreign Agent Care of Address through the 
PDP Context Activation procedure. 

In TETRA Packet data, a MS shall indicate if it wishes to avail of Mobile IP services in the SN-ACTIVATE PDP 
CONTEXT DEMAND PDU by setting "Address Type Identifier in Demand" to "Mobile IPv4 Foreign Agent Care-of 
Address" or "Mobile IPv4 Co-located Care-of Address". A SwMI which offers support for Mobile IP services may 
respond with a "Mobile IPv4 Care-of Address" plus further information within the information element "SwMI Mobile 
IPv4 Information" of the SN-ACTIVATE PDP CONTEXT ACCEPT PDU. 

28.3.3.1.3 IPv6 

IPv6 will support two methods for a host to obtain a global IPv6 address. Stateful address autoconfiguration shall enable 
a host to be dynamically allocated an IP address through the use of a protocol such as Dynamic Host Configuration 
Protocol (DHCPv6). This will operate in a similar way to dynamic address allocation in IPv4. Stateless address 
autoconfiguration enables a host to generate its own IP address through information broadcast on the network where it 
is camped. The IPv6 address is 128 bits compared to 32 bits in IPv4. The address is broken into two parts, the Link 
Prefix and the Interface Identifier as shown in figure 28.9. 



Link Prefix | Interface Identifier 

— - 64 bits > < - 64 bits 



Figure 28.9: Ipv6 address 
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In the case of both address autoconfiguration methods, the IPv6 node must first generate a link local IPv6 address. A 
link-local IPv6 address may only be used on the link or subnet to which the node is connected. To generate a link local 
address, an IPv6 node combines an Interface-Identifier with the Link Prefix which has been reserved for link local 
addresses. The IPv6 node will then use this link local IPv6 address to obtain a global IPv6 address. Typically this will 
involve sending a Router Solicitation and receiving a Router Advertisement. 

In TETRA Packet data, a MS indicates in the SN-ACTIVATE PDP CONTEXT DEMAND PDU whether it wishes to 
use IPv6 services by setting "Address Type Identifier in Demand" appropriately. 

Where the SwMI indicates in a SN-ACTIVATE PDP CONTEXT ACCEPT PDU that IPv6 is supported, the MS may 
then use a link local IPv6 address to perform stateful or stateless address autoconfiguration. 

It is recommended that when generating a link local IPv6 address, the MS shall use its ITSI as the 48 least significant 
bits of the Interface Identifier thus ensuring that the Interface Identifier is unique on the link or subnet. A further 
requirement for Interface Identifier, is for the 6th most significant bit to be set to zero. All other bits of the Interface 
Identifier may be set to zero or may be used to support multiple link local addresses per ITSI. 

This version of the packet data specification does not specify how IPv6 service is provided by a SwMI or the actions 
which a MS must take in order to obtain a global IPv6 address. Where a SwMI sends a SN-ACTIVATE PDP 
CONTEXT ACCEPT PDU indicating that it supports IPv6 services, it is recommended that the SwMI then prepares to 
receive a Router Solicitation and respond with a Router Advertisement. 

28.3.3.2 NSAPI usage 

The set of protocol entities above SNDCP uses the same SNDCP entity, which then performs multiplexing of data 
coming from different sources to be sent across a single LLC connection. Sharing a single LLC connection requires that 
different addresses can be identified. The NSAPI field of four bits is used for this purpose, defining the end user PDP 
type and PDP address pair that the MS is using. Following values are reserved for special use: 

• is reserved; 

• 15 is reserved. 

NOTE 1 : The user application should start from NSAPI value 1 when allocating the first PDP context. 
Other values are allocated dynamically. The allocation of the dynamic NS APIs can be e.g. following: 

• IPv4: 133.12.75.111 => NSAPI = 2 

• IPv4: 133.12.75.222 => NSAPI = 3 

NOTE 2: NSAPI may be used also for routing between MT and TE, e.g. NSAPI = 2 is activated by the TE2 and 

NSAPI = 3 is activated by the MT (actually MTO to be exact i.e. the MS may act as MTO and MT2 at the 
same time). The MEX layer may be used to provide this routing service (see clause 30.3.7). 

NOTE 3: Data arriving in SNDCP via a secondary PDP context should be routed according to the NSAPI of the 
primary PDP context. 

Since the adaptation of different higher layer protocol to SNDCP is implementation dependent, it is not defined in the 
present document. 

28.3.3.3 SNDCP network endpoint identifier 

Within the SwMI, there may be a requirement for multiple SNDCP entities in order to provide load balancing or to 
provide packet data service for different geographical regions. In order to support the existence of multiple such 
SNDCP entities within the SwMI, a SNDCP Network Endpoint Identifier (SNEI) may be assigned to each MS at PDP 
Context Activation. The SNEI information element shall only be present in uplink communication when the SwMI has 
assigned a SNEI value to the MS during context activation. Where the MS has been assigned a SNEI value during PDP 
context activation, then there are four occasions where the MS shall include the SNEI as part of uplink communication: 

1 . When in READY state and after performing a cell change, the MS SNDCP entity shall include the SNEI as 
part of the Reconnect message (see clause 28.3.4.2 c) if the BS does not support QAM modulation - the SNEI 
does not need to be included if the BS supports QAM modulation; 
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2. When requesting permission to transmit data to a BS which does not support QAM modulation, the MS 
SNDCP entity shall include the SNEI - the SNEI does not need to be included if the BS supports QAM 
modulation; 

3. When responding to a page from the SwMI, the MS SNDCP entity shall include the SNEI if the BS does not 
support QAM modulation - the SNEI does not need to be included if the BS supports QAM modulation; 

4. When deactivating a PDF context, the MS SNDCP entity shall include the SNEI if BS does not support QAM 
modulation - the SNEI does not need to be included if the BS supports QAM modulation. 

A BS which supports QAM modulation shall have an alternative method of discovering an MS's SNEI. 

The SwMI may assign a new SNEI to a MS in any of the following circumstances: 

1 . When activating a new PDP context; 

2. When responding to a request from a MS to transmit data; 

3. When paging a MS. 

On reception of a new SNEI value, the MS SNDCP entity should store this value for later use. The value of SNEI which 
the MS shall send to the SwMI during uplink communication shall be the most recently received SNEI. The SwMI shall 
only assign one SNEI per ITSI. The most recently received SNEI shall apply to all PDP contexts for a given ITSI. 

The usage of the SNEI within the SwMI is outside the scope of the present document. 

28.3.3.4 Definition of Packet data MS Types 

The following clauses 28.3.3.4.1 to 28.3.3.4.4 describe the service interactions between circuit mode, messaging and 
packet data services as defined by the value of the Packet data MS Type information element. The types have meaning 
only in the context of TETRA Packet data. It is used by the MS to indicate to the SwMI its service interaction 
capabilities between packet data and individual circuit mode speech and data calls. The Packet data MS Type is sent to 
the SwMI when activating PDP context. If the Packet data MS Type is changed after the first PDP context activation, 
then the SwMI shall use the Packet data MS Type value, as received in the latest PDP activation. 

NOTE 1: If the SwMI rejects a PDP context activation with the Activation reject cause set as "Packet Data MS type 
not supported" the MS may retry the PDP context activation with a lower Packet Data MS type e.g. if the 
SwMI rejects a Packet Data MS type of A the MS may try to activate a context as a Packet Data MS type 
of B, C or D. How the MS determines which Packet Data MS type to choose following a PDP context 
activation rejection is outside the scope of the present document. 

The SwMI may use the Packet data MS type value to assist in optimizing air interface signalling when offering packet 
data services to an MS. For example the SwMI may choose not to offer (because the MS will probably not accept): 

• TETRA Packet data to type D and C MS which is engaged in a circuit mode speech/data; 

• Circuit mode speech/data to type D and C MS which is engaged in TETRA Packet data. 

NOTE 2: If the MS is offered a circuit mode service, it may choose to ignore, reject or accept the service. The 

criteria for the MS to ignore, reject or accept the service are outside the scope of the present document. 

In addition SwMI should be aware that type B MS shall abandon TETRA Packet data temporarily if it accepts or 
initiates circuit mode speech/data and vice versa. Type A MS may preserve both services parallel. 

NOTE 3: SN-NSAPI ALLOC request primitive does not contain MS TETRA Packet data Type as a parameter. 
This is because the type may be constrained by the capabilities of the MS. 

NOTE 4: An MS should always be capable of making an emergency call set up irrespective of the packet data MS 
Type and packet data state. 

NOTE 5: How the SwMI determines the circuit mode status of an MS is outside the scope of the present document. 

NOTE 6: The SwMI can only optimize the air interface signalling when interacting with individual calls. 

Interaction with group calls and Supplementary Services is outside the scope of the present document. 
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The different types for TETRA Packet data MSs and their capabihties to handle other services in addition to TETRA 
Packet data are summarized in table 28.14a. 

Table 28.14: Packet data MS types and other services 



Service 


Type A 


Type B 


TypeC 


Type D 


Circuit mode speech/data conducted in 
READY state 


X 








Circuit mode speecli/data set up in 
READY state 


X 


X 






SDS in READY state 


X 


X 


X 




Circuit mode speech/data conducted in 
STANDBY state 


X 


X 


X 


X 


TETRA Pacl<et Data 


X 


X 


X 


X 



28.3.3.4.1 



Type A - Parallel 



AH services (SDS, Circuit mode speech/data) may be conducted parallel with TETRA Packet data. MS has the 
capability to receive/send both circuit mode speech/data and TETRA Packet data at the same time. This means that 
circuit mode speech/data may be set up, accepted and conducted while the MS is in READY state. SDS may be 
conducted while the MS is in READY state. 

NOTE: This MS can only support concurrent Packet data and circuit mode if the appropriate resources matching 
the "Class of MS" (refer to clause 16.10.5) can be allocated by the SwMI. 



28.3.3.4.2 



Type B - Alternating 



Other services (SDS, Circuit mode speech/data) may be conducted alternating with TETRA Packet data, i.e. if MS is 
engaged in TETRA Packet data it may accept circuit mode speech/data and vice versa but only one service (TETRA 
Packet data or circuit mode speech/data) can be active at any time. SDS can be conducted parallel both with TETRA 
Packet data and circuit mode speech/data. This means that circuit mode speech/data may be set up but not conducted 
while the MS is in READY state. Circuit mode speech/data may be only conducted in STANDBY state. 



28.3.3.4.3 



Type C - IP single mode 



The MS is engaged to one service at a time; if MS is engaged in TETRA Packet data it does not accept circuit mode 
speech/data and vice versa: 

1. While the MS is in the READY state i.e. engaged in TETRA Packet Data, no circuit mode speech/data calls 
may be set up, accepted or conducted. However, SDS may be conducted while the MS is in the READY state. 

2. While the MS has an ongoing circuit mode speech/data call or is in the call set up phase, TETRA Packet data 
is not allowed (accepted or initiated). This means that circuit mode speech/data may be set up, accepted or 
conducted while the MS is in STANDBY state. SDS may also be conducted while the MS is in the STANDBY 

state. 

NOTE: Circuit mode calls in the STANDBY state are only permitted if allowed by the "Class of MS" (refer to 
clause 16.10.5). 



28.3.3.4.4 



Type D - Restricted IP single mode 



The MS is engaged to one service at a time; if MS is engaged in TETRA Packet data it does not accept circuit mode 
speech/data and does not support SDS and vice versa: 

1. While the MS is in the READY state i.e. engaged in TETRA Packet Data, no circuit mode speech/data may 
calls be set up, accepted or conducted. SDS should not be conducted while the MS is in READY state. 

2. While the MS has an ongoing circuit mode speech/data call or is in the call set up phase, TETRA Packet data 
is not allowed (accepted or initiated). This means that circuit mode speech/data may be set up, accepted or 
conducted while the MS is in STANDBY state. SDS may also be conducted while the MS is in the STANDBY 

state. 
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28.3.3.5 PDP Context Activation Procedure 

Successful PDP Context Activation procedure is illustrated in figure 28.10. Each numbered step is explained in the 
following list. 

NOTE: In figures 28.10 to 28.13 the PDU names are presented without an "SN-" preamble. 





MS 




SwMI 




1. SN-NS API Alloc rea 


7 Artivatp PDP Cnntp-xt DpmanH 








► 








J. Activate PDP Context Accept 


4. SN-NSAPI Alloc ind 






^ 


. 5. SN-NSAPI Alloc cnf 


w 


^ 







Figure 28.10: PDP Context activation procedure - activation accepted 

1. The SN-SAP user triggers PDP context activation by issuing a SN-NSAPI ALLOC request primitive. 

2. The MS sends an SN-ACTIVATE PDP CONTEXT DEMAND PDU to the SwMI. The MS indicates the form 
of IP address it wishes to use in the information element "Address Type Identifier in Demand". If supported, 
the MS shall request the QoS it requires in the "QoS" information element. The requested QoS shall be derived 
from information in the NSAPI QoS negotiation parameter of the SN-NSAPI ALLOC request primitive. The 
MS shall start PDP_ACTIVATE_WAIT timer. 

3. SwMI inserts the NSAPIs in its PDP Contexts. The SwMI returns an SN-ACTIVATE PDP CONTEXT 
ACCEPT PDU to the MS . The SwMI is now able to route PDP PDUs to and from MS. If the MS indicated a 
QoS requirement, the SwMI shall, if supported, indicate the QoS it expects to provide for this PDP context in 
the "QoS" information element. The MS shall stop PDP_ACTIVATE_WAIT timer. 

4. The SwMI SN-SAP user is informed about PDP context activation by the SwMI SNDCP issuing SN-NSAPI 
ALLOC indication primitive. 

5. The MS SN-SAP user is informed about successful PDP context activation and any negotiated QoS by the MS 
SNDCP issuing SN-NSAPI ALLOC confirm primitive. 

Unsuccessful PDP Context Activation procedure due to SwMI rejection is illustrated in figure 28. 11 . Each numbered 
step is explained in the following list. 



MS 



1. SN-NSAPI Alloc rec 



4. SN-NSAPI Alloc cnf 



SwMI 



2. Activate PDP Context Demand 



3 . Activate PDP Context Reject 



Figure 28.11 : PDP context activation procedure - activation rejected 
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1. The SN-SAP user triggers PDP context activation by issuing SN-NSAPI ALLOC request primitive. 

2. The MS sends an SN-ACTIVATE PDP CONTEXT DEMAND PDU to the SwML The MS shall start 
PDP_ACTIVATE_WAIT timer. 

3. SwMI rejects activation by returning a SN-ACTIVATE PDP CONTEXT REJECT PDU to the MS. The MS 
shall stop PDP_ACTIVATE_WAIT timer. 

4. The MS SN-SAP user is informed about unsuccessful PDP context activation by the MS SNDCP issuing 
SN-NSAPI ALLOC confirm primitive. 

Unsuccessful PDP Context Activation procedure due to expiry of PDP_ACTIVATE_WAIT timer is illustrated in the 
figure 28.12. Each numbered step is explained in the following list. 



MS 



1. SN-NSAPI Alloc rec 



3. SN-NSAPI Alloc cnf 



SwMI 



2. Activate PDP Context Demand 



Start PDP_ACTIVATE^WAIT 



Expiry of PDP_ACTIVATE_WAIT 



Figure 28.12: PDP context activation procedure - no response to activation 

1. The SN-SAP user triggers PDP context activation by issuing SN-NSAPI ALLOC request primitive. 

2. The MS sends an SN-ACTIVATE PDP CONTEXT DEMAND PDU to the SwMI. The MS shall start 
PDP_ACTIVATE_WAIT timer. 

3. Timer PDP_ACTIVATE_WAIT timer expires. The MS SN-SAP user is informed about unsuccessful PDP 
context activation by the MS SNDCP issuing SN-NSAPI ALLOC confirm primitive. 

Unsuccessful PDP Context Activation procedure due to wrong NSAPI in the SwMI's response is illustrated in the 
figure 28.13. Each numbered step is explained in the following list. 



MS 



1. SN-NSAPI Alloc reg 



5. SN-NSAPI Alloc con 



SwMI 



2. Activate PDP Context Demand (NSAPI=3) 



3. Activate PDP Context Accept (NSAPI=2) 



6. Deactivate PDP Context Demand (NSAPI=2W 

7. Deactivate PDP Context Accept (NSAPI=2) 



4. SN-NSAPI Alloc ind 



8. SN-NSAPI Dealloc ind 



Figure 28.13: PDP context activation procedure - wrong NSAPI 
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1. The SN-SAP user triggers PDP context activation by issuing SN-NSAPI ALLOC request primitive. 

2. The MS sends an SN-ACTIVATE PDP CONTEXT DEMAND PDU to the SwML The MS shall start 
PDP_ACTIVATE_WAIT timer. 

3. SwMI inserts the NSAPIs in its PDP Contexts. The SwMI returns an SN-ACTIVATE PDP CONTEXT 
ACCEPT PDU to the MS. The MS shall stop the PDP_ACTIVATE_WAIT timer. 

4. The SwMI SN-SAP user is informed about PDP context activation by the SwMI SNDCP issuing SN-NSAPI 
ALLOC indication primitive. 

5. The NSAPI in the Demand and Accept differ, and hence the MS SN-SAP user is informed about the failed 
PDP context activation by the MS SNDCP issuing SN-NSAPI ALLOC confirm primitive. 

6. The MS deactivates the NSAPI issued by the SwMI by sending a SN-DEACTIVATE PDP CONTEXT 
DEMAND PDU to the SwMI. The MS shall start the PDP_DEACTIVATE_WAIT timer. 

7. The SwMI shall respond by sending a SN-DEACTIVATE PDP CONTEXT ACCEPT PDU to the MS. On 
reception of the SN-DEACTIVATE PDP CONTEXT ACCEPT PDU, the MS shall stop the 
PDP_DEACTIVATE_WAIT timer. 

8. The SwMI SN-SAP user is informed about PDP context deactivation by the SwMI SNDCP issuing SN-NSAPI 
DEALLOC indication primitive. 

If the PDP context activation procedure fails, then the MS SNDCP service user may attempt another activation to the 
same PDP Address up to a maximum number RETRY_ACTIVATION of attempts. 

28.3.3.5a PDP context modification procedure 

It is optional for an MS and SwMI to support PDP context modification. 

Normally, MSs should be responsible for initiating PDP context modification, either because the application's QoS 
requirements have changed, or because the MS has observed that the SwMI is no longer able to provide the previously 
agreed QoS. 

The SwMI shall not attempt to increase an already agreed QoS by PDP context modification. The SwMI is not required 
to modify PDP contexts every time the available QoS changes. The SwMI may initiate modification of a PDP context if 
it becomes unable to support a previously agreed schedule for slot grants on that PDP context. See also clause 28.3.5.6. 

The MS shall not reject a SwMI-initiated PDP context modification. 

Successful PDP Context modification procedure initiated by the MS is illustrated in the figure 28.14. Each numbered 
step is explained in the following list. 

NOTE: In figures 28.14 to 28.18 the PDU names are presented without an "SN-" preamble. 





MS 




SwMI 




1. SN-NSAPI Modify 


req 


2. Mo 


rlifv PDP context reniiesf 








w 








w 

3. Modify PDP context response 
_^ (modification applied) 


4. SN-NSAPI Modify ind 




% 


^ 


5. SN-NSAPI Modify cnf 


w 


^ 







Figure 28.14: MS-initiated PDP Context modification procedure - modification accepted 
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1 . The MS's SN-S AP user triggers PDP context modification by issuing a SN-NS API MODIFY request 
primitive. 

2. The MS sends an SN-MODIFY PDP CONTEXT REQUEST PDU containing a proposed QoS to the SwMI. 
The MS shall start PDP_MODIFY_WAIT timer. 

3. SwMI modifies its recorded QoS information for the PDP context and returns an 

SN-MODIFY PDP CONTEXT RESPONSE PDU (modification result = modification applied) to the MS, 
including a modified QoS information element. (The modified QoS does not need to match the QoS 
information element in the modification request, but it shall differ from the previously agreed QoS). 
SN-DATA and SN-UNITDATA PDUs for this PDP context should now experience the modified QoS. The 
MS shall stop the PDP_MODIFY_WAIT timer. 

4. The SwMI SN-SAP user is informed about the PDP context modification by the SwMI SNDCP issuing a 
SN-NSAPI MODIFY indication primitive primitive. 

5. The MS SN-SAP user is informed about the PDP context modification by the MS SNDCP issuing a 
SN-NSAPI MODIFY confirm primitive. 

The SwMI shall initiate PDP context modification only when it needs to reduce the level of the presently agreed QoS. 
Successful PDP Context modification procedure initiated by the SwMI is illustrated in the figure 28.15. Each numbered 
step is explained in the following list. 



MS 



4. SN-NSAPI Modify ind 
-^ 



SwMI 



2. Modify PDP context request 



3. Modify PDP context response 
(modification applied) 



1. SN-NSAPI Modify req 



5. SN-NSAPI Modify cnf 



2. 
3. 



5. 



Figure 28.15: SwMI-initiated PDP Context modification procedure - modification accepted 

The SwMI SN-SAP user triggers PDP context modification by issuing a SN-NSAPI MODIFY request 
primitive. 

The SwMI sends an SN-MODIFY PDP CONTEXT REQUEST PDU containing a modified QoS to the MS. 

The MS modifies its recorded QoS information for the PDP context and returns an 

SN-MODIFY PDP CONTEXT RESPONSE PDU (modification result = modification applied) to the SwMI, 

including a modified QoS information element. (The modified QoS shall match the the QoS information 

element in the modification request). PDP PDUs for this PDP context should now experience the modified 

QoS. 

The MS SN-SAP user is informed about PDP context modification by the SwMI SNDCP issuing 
SN-NSAPI MODIFY indication primitive. 

The SwMI SN-SAP user is informed about the PDP context modification by the MS SNDCP issuing 
SN-NSAPI MODIFY confirm primitive. 



NOTE: The SwMI may also initiate PDP context modification as a result of SwMI layer 2 changes, without first 
receiving a SN-NSAPI MODIFY request primitive. In this case, the SwMI should inform the SwMI 
SN-SAP user of the change in QoS by issuing a SN-NSAPI MODIFY indication primitive (and not a 
SN-NSAPI MODIFY confirm primitive). 

The MS shall not reject a PDP context modification initiated by the SwMI (but it may subsequently deactivate the 
modified PDP context, or attempt to modify it). 

Unsuccessful PDP context modification procedure due to SwMI rejection is illustrated in the figure 28.16. Each 
numbered step is explained in the following list. 
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MS 




SwMI 


l.SN-NS API Modify 


req 


2. Modify PDF context request 






w 


X.. lYiUUllJ. i i^i y^UllLV^Al, IV^lJUV^Cl. 






3. Modify PDP context response 
^ (modification rejected) 




\. SN-NSAPI Modify cnf 


^ 




^ 







Figure 28.16: MS-initiated PDP context modification procedure - modification rejected by SwIUli 

1. The SN-SAP user triggers PDP context modification by issuing a SN-NSAPI MODIFY request primitive. 

2. The MS sends an SN-MODIFY PDP CONTEXT REQUEST PDU containing a proposed QoS to the SwMI. 
The MS shall start PDP_MODIFY_WAIT timer. 

3. SwMI rejects modification by returning a SN-MODIFY PDP CONTEXT RESPONSE PDU 
(modification result = modification rejected) to the MS. The QoS previously agreed for the PDP context 
remains unchanged. The MS shall stop PDP_MODIFY_WAIT timer. 

4. The MS SN-SAP user is informed about unsuccessful PDP context modification by the MS SNDCP issuing a 
SN-NSAPI MODIFY confirm primitive. 

Unsuccessful PDP Context Modification procedure due to expiry of PDP_MODIFY_WAIT timer is illustrated in the 
figure 28.17. Each numbered step is explained in the following list. 



MS 



1. SN-NSAPI Modify req 



3. SN-NSAPI Modify cnf 



2. Modify PDP context request 



Start PDP_MODIFY_WAIT 



Expiry of PDP_MODIFY_WAIT 



SwMI 



Figure 28.17: lUIS-initiated PDP context modification procedure - no response to modification request 

1. The SN-SAP user triggers PDP context modification by issuing a SN-NSAPI ALLOC request primitive. 

2. The MS sends an SN-MODIFY PDP CONTEXT REQUEST PDU to the SwMI. The MS shall start 
PDP_MODIFY_WAIT timer. 

3. Timer PDP_MODIFY_WAIT timer expires. The MS SN-SAP user is informed about unsuccessful PDP 
context modification by the MS SNDCP issuing a SN-NSAPI MODIFY confirm primitive. 



£75/ 



942 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



Unsuccessful MS-initiated PDP context modification procedure due to MS receiving a 

SN-MODIFY PDP CONTEXT REQUEST PDU from the SwMI while the PDP_MODIFY_WAIT timer is active is 

illustrated in the figure 28.18. Each numbered step is explained in the following list. 



MS 



1. SN-NS API Modify req 



5. SN-NS API Modify cnf 

< 



7. SN-NSAPI Modify ind 
< 



SwMI 



2. Modify PDP context request 




Modify PDP context request 



6. Modify PDP context response 
(modification accepted) 



3. SN-NSAPI Modify req 



8. SN-NSAPI Modify cnf 



Figure 28.18: MS-initiated PDP context modification procedure - 
SwIVII also initiating modification of the same PDP context 

1. The SN-SAP user triggers PDP context modification by issuing a SN-NSAPI MODIFY request primitive. 

2. The MS sends an SN-MODIFY PDP CONTEXT REQUEST PDU. The MS shall start PDP_MODIFY_WAIT 

timer. 

3. The SwMI SN-SAP user triggers PDP context activation by issuing SN-NSAPI MODIFY request primitive. 

4. The SwMI SNDCP sends an SN-MODIFY PDP CONTEXT REQUEST PDU containing a proposed QoS to 
the MS before it receives the SN-MODIFY PDP CONTEXT RESPONSE PDU from the MS. The SwMI shall 
now discard any SN-MODIFY PDP CONTEXT REQUEST PDU received from the MS until after it receives 
SN-MODIFY PDP CONTEXT RESPONSE PDU (modification result = modification applied) from the MS. 

5. On receipt of SN-MODIFY PDP CONTEXT REQUEST PDU while the PDP_MODIFY_WAIT timer is 
active, the MS SNDCP informs the MS SN-SAP user about unsuccessful PDP context modification by issuing 
SN-NSAPI MODIFY confirm primitive. The MS shall stop PDP_MODIFY_WAIT timer. 

6. The MS SNDCP sends receives SN-MODIFY PDP CONTEXT RESPONSE PDU (modification result = 
modification applied) to the SwMI. 

7. The MS SN-SAP user is informed about PDP context modification by the MS SNDCP issuing 
SN-NSAPI MODIFY indication primitive. 

8. The SwMI SN-SAP user is informed about the PDP context modification by the SwMI SNDCP issuing 
SN-NSAPI MODIFY confirm primitive. 

In general, if MS-initiated PDP context modification procedure fails, then the MS SNDCP service user may attempt an 
identical modification of that PDP context up to a maximum number RETRY_MODIFICATION of attempts before 
deactivation of the PDP context. 
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28.3.3.6 PDP context deactivation procedure 

Either a MS or the SwMI may initiate the deactivation procedure. 



28.3.3.6.1 



MS originated PDP context deactivation procedure 



MS originated PDP Context Deactivation procedure is illustrated in the figure 28.19. Each numbered step is explained 
in the following list. 

NOTE: In the figures 28.19 to 28.21 the PDU names are presented without an "SN-" preamble. 



MS 



l.SN-NSAPIDeallocreq 



SwMI 



2. Deactivate PDP Context Demand 



^ . Deactivate PDP Context Accept 



4. SN-NSAPI Dealloc ind 



Figure 28.19: PDP context deactivation procedure 

1. The SN-SAP user triggers PDP context deactivation by issuing SN-NSAPI DEALLOC request primitive. 

2. The MS sends a SN-DEACTIVATE PDP CONTEXT DEMAND PDU to the SwMI. The MS shall start 
PDP_DEACTIVATE_WAIT timer. 

3. The SwMI returns a SN-DEACTIVATE PDP CONTEXT ACCEPT PDU to the MS. The MS shall stop 
PDP_DEACTIVATE_WAIT timer. 

4. The SwMI SN-SAP user is informed about PDP context deactivation by the SwMI SNDCP issuing SN-NSAPI 
DEALLOC indication primitive. 

5. The MS SN-SAP user is informed about PDP context deactivation by the MS SNDCP issuing an SN-NSAPI 
DEALLOC confirm primitive. 

MS originated PDP Context Deactivation unsuccessful procedure due to expiry of PDP_DEACTIVATE_WAIT timer is 
illustrated in the figure 28.20. Each numbered step is explained in the following list. 



MS 



l.SN-NSAPIDeallocreq 



(NSAPl = 2) 



3. SN-NSAPI Dealloc req 



(NSAPl = 3) 



SwMI 



2. Deactivate PDP Context Demand (NSAPl = 2) 



Start PDP DEACTIVATE WAIT 



Expiry of PDP_DEACTIVATE_WAIT 

3. Deactivate PDP Context Demand (NS API = 3) 



2. 



Figure 28.20: PDP context deactivation procedure - no response to deactivation 

The SN-SAP user triggers PDP context deactivation by issuing SN-NSAPI DEALLOC request primitive 
(NSAPl = 2 in this scenario). 

The MS sends a SN-DEACTIVATE PDP CONTEXT DEMAND PDU (NSAPl = 2 in this scenario) message 
to the SwMI. The MS shall start PDP_DEACTIVATE_WAIT timer. 
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3. The SN-SAP user triggers PDP context deactivation by issuing SN-NSAPI DEALLOC request primitive 
(NSAPI = 3 in this scenario). 

4. Timer PDP_DEACTIVATE_WAIT timer expires. The MS shall not retry de-activation procedure for that 
NSAPI= 2 . The PDP context is deactivated locally. 

5. The MS sends a Deactivate PDP Context Demand (NSAPI = 3 in this scenario) message to the SwMI. The MS 
shall start PDP_DEACTIVATE_WAIT timer. 

The MS may use Deactivation type parameter value "Deactivation of all NS APIs" when sending 
the SN-DEACTIVATE PDP CONTEXT DEMAND PDU. Should this happen the MS shall deactivate all its active 
PDP Contexts locally. The SwMI shall respond to the Demand by sending a SN-DEACTIVATE PDP CONTEXT 
ACCEPT PDU having Deactivation type parameter value "Deactivation of all NSAPIs" and deactivate all NSAPIs for 
that MS. 



28.3.3.6.2 



SwMI originated context deactivation procedure 



SwMI originated PDP Context Deactivation procedure is illustrated in the figure 28.21. Each numbered step is 
explained in the following list. 



MS 



SN-NSAPI Dealloc ind 



(NSAPI = 3) 



SwMI 



2. Deactivate PDP Context Demand 



' (NSAPI = 3) 



3. Deactivate PDP Context Accept 



(NSAPI = 3) 



1. SN-NSAPI Dealloc req 



(NSAPI = 3) 



2. 
3. 



Figure 28.21 : SwMI originated PDP context deactivation procedure 

The SN-SAP user triggers PDP context deactivation by issuing SN-NSAPI DEALLOC request primitive 
(NSAPI = 3 in this scenario). 

The SwMI sends a SN-DEACTIVATE PDP CONTEXT DEMAND PDU to the MS. 

The MS sends a SN-DEACTIVATE PDP CONTEXT ACCEPT PDU to the SwMI. 



4. The MS SN-SAP user is informed about PDP context deactivation by the MS SNDCP issuing 
SN-NSAPI DEALLOC indication primitive 

In a case of failed PDP Context deactivation the SwMI may retry deactivation. 

The SwMI may use Deactivation type parameter value "Deactivation of all NSAPIs" when sending 
the SN-DEACTIVATE PDP CONTEXT DEMAND PDU. Should this happen, the MS shall respond to the demand by 
sending a SN-DEACTIVATE PDP CONTEXT ACCEPT PDU having Deactivation type parameter value "Deactivation 
of all NSAPIs" and deactivate all NSAPIs locally. 

28.3.3a Assignment of layer 2 logical links to PDP contexts 

Four different types of layer 2 logical links are available for transmission of N-PDUs. These are: 

• original acknowledged advanced link; 

• extended acknowledged advanced link; 

• unacknowledged advanced link; and 

• unacknowledged basic link. 
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The MS may support up to four acknowledged advanced links. One of these may be an original advanced link or an 
extended advanced link. The other three shall be extended advanced links. Extended advanced links may use a larger 
transmission window size than the original advanced link, and this may be beneficial where multiple applications are 
using the same link. However, extended advanced links have slightly less capacity than the original advanced link. 

Information about the support by the SwMI for the extended advanced links is broadcast to the MS in section 1 of the 
extended services broadcast information element of the MAC SYSINFO PDU and the MAC SYSINFO-Q PDU and is 
passed to the MS SNDCP in the MLE-INFO primitive. 

The MS may also support up to four unacknowledged advanced links per address and a single unacknowledged basic 
link. 

The MS SNDCP shall assign a layer 2 link to a PDP context before transmitting or receiving SN-DATA or 
SN-UNITDATA PDUs for that PDP context. 

The MS SNDCP shall request the MS LLC to set up acknowledged advanced links when required, and the SwMI shall 
set up unacknowledged advanced links when required (see clause 28.3.4.2). The unacknowledged basic link does not 
require setting up. 

If the MS and SwMI negotiated QoS during activation of the PDP context, the MS's choice of layer 2 logical link type 
shall be based on the data class information element included in the QoS information element of the most recently 
exchanged SN-ACTIVATE PDP CONTEXT ACCEPT PDU or SN-MODIFY PDP CONTEXT RESPONSE PDU for 
that PDP context. If the MS and SwMI did not negotiate QoS during PDP context activation, the MS SNDCP shall 
assign an acknowledged advanced link to the PDP context. Table 28.15 specifies how the MS's choice of logical link 
type depends on negotiated data class and use of QoS negotiation. 

Table 28.15: Assignment of layer 2 logical link type to PDP context 



Data class 


Link type 


Background 


Acknowledged advanced link 


Telemetry 


Acknowledged advanced link 


Real-time 


Unacknowledged basic link 


QoS not negotiated 


Acknowledged advanced link 



The MS SNDCP shall assign one of the available advanced links to a PDP context before the MS or SwMI commences 
transmitting SN-DATA PDUs for that PDP context. The MS SNDCP may use the contents of the QoS parameter in the 
most recently exchanged SN-ACTIVATE PDP CONTEXT ACCEPT PDU or SN-MODIFY PDP CONTEXT 
RESPONSE PDU (containing modify type = "response") for that PDP context, if available, to assist in its choice of 
acknowledged advanced link identifier and type (original or extended). If the MS and SwMI did not negotiate QoS 
during PDP context activation, the MS should choose an acknowledged advanced link suitable for background class 
data (see clause 28.3.3b). 

When assigning particular acknowledged advanced links to PDP contexts, the MS may choose to group PDP contexts 
requiring the same data class and reliability class on the same acknowledged advanced link. When an advanced link is 
required, the MS SNDCP may request LLC to set up the acknowledged advanced link with a TL-SDU window size, 
maximum number of TL-SDU transmissions and maximum number of segment retransmissions suited to the QoS 
requirements of the PDP contexts assigned to that link (see clause 28.3.3b). 

When the SwMI transmits an SN-DATA PDU, it should use the most suitable existing acknowledged advanced link. 

If the MS receives an individually addressed SN-DATA TRANSMIT REQUEST for a PDP context whose assigned 
acknowledged advanced link has not been set up, the MS should set up the assigned acknowledged advanced link as 
soon as the MS reaches the PDCH. If the SwMI has already started using a different acknowledged advanced link, the 
SwMI should change to the new, more suitable link when it has delivered all the SN-DATA PDUs already being sent on 
the previous acknowledged advanced link for that PDP context, if it thinks the new advanced link is more suitable. 

When the SwMI wishes to transmit unacknowledged packet data to one or more MSs, it may use the unacknowledged 
basic link (e.g. for real-time class data) or it shall set up and use an unacknowledged advanced link. 
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28.3.3b Choice of layer 2 logical link parameters 

When setting up an acknowledged advanced link, the MS should attempt to set the parameters to suit the QoS 
requirements of the PDP contexts assigned to use that link. 

An advanced link assigned for telemetry class data may be given a window size greater than 1 to help the transmitter to 
catch up with the schedule after a scheduled grant is missed or a transmission fails, but kept small (e.g. N.272 = 2 or 3) 
to limit the loss of partially delivered TL-SDUs if the link has to be reset. The maximum number of TL-SDU 
retransmissions (N.273) and the maximum number of segment retransmissions (N.274) may be set to a small number 
(e.g. 2 or 3), so that the transmitter can abandon an undelivered TL-SDU, reset the advanced link and move on to the 
new TL-SDU before too much delay is incurred. 

An advanced link assigned for use by background class data may be given a large window size (e.g. N.272 = 15), a 
large maximum number of TL-SDU retransmissions (e.g. N.273 = 7) and a large maximum number of segment 
retransmissions (e.g. N.274 = 15) to maximize the chance of ultimately delivering the TL-SDU. 

SNDCP should set the FCS flag in the MLE-UNITDATA request primitive to instruct the LLC to use the FCS when 
transmitting an SN-DATA PDU containing best effort class data or telemetry class data requiring high reliability. 
SNDCP should set the FCS flag to instruct the LLC not to use an FCS when transmitting an SN-UNITDATA PDU 
containing real-time class data. 

28.3.4 Packet Data Channel (PDCH) handling procedures 

The control channel procedures specified in the present document apply for TETRA packet data. The control channel 
used for TETRA packet data SN-PDU transfer is called the Packet Data Channel (PDCH). The SwMI may add channel 
allocation to SN-DATA TRANSMIT REQUEST PDU (Data from SwMI to MS). The SwMI may add channel 
allocation to SN-DATA TRANSMIT RESPONSE PDU (data from MS to SwMI) if the MS's request to transmit is 
accepted by the SwMI. 

Clause 28.3.4.8 describes how the SwMI should select an appropriate PDCH. 

The channel is released by the SwMI by issuing SN-END OF DATA PDU when SwMI's READY timer expires. Where 
the MS was directed to the PDCH using a channel allocation, then the SN-END OF DATA PDU shall include channel 
allocation to common control channel. If the READY timer expires in the MS, then the MS shall issue SN-END OF 
DATA PDU and await a corresponding SN-END OF DATA PDU from the SwMI. 

NOTE 1: The case where the READY timer expires in the MS prior to reception of a SN-END OF DATA PDU 

should be viewed as an exceptional case. To ensure the MS receives a SN-END OF DATA PDU from the 
SwMI before its READY timer expires, the SwMI should set its own READY timer to a shorter value 
than the one sent to the MS in the SN-ACTIVATE PDP CONTEXT ACCEPT PDU. 

NOTE 2: The packet channel is defined from a single MS point of view (except when the SwMI uses multicast 

address). Thus here releasing the PDCH means releasing the channel for a single MS. In the same control 
channel there may be also more than one MS at the same time. 

NOTE 3: The MS may choose to adjust its value of T.208 against READY timer on a PDCH to ensure that the use 
of SN-END OF DATA will be the normal way of leaving a PDCH. 
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28.3.4.1 Logical link handling 

Table 28.16 defines the division between basic link and advanced link based on SN-PDU type. 

Table 28.16: Logical link usage by SN-PDUs 



SN-PDU 


Basic link 


Advanced links 


SN-ACTIVATE PDP CONTEXT DEMAND 


X 




SN-DEACTIVATE PDP CONTEXT DEMAND 


X 




SN-ACTIVATE PDP CONTEXT ACCEPT 


X 




SN-ACTIVATE PDP CONTEXT REJECT 


X 




SN-DEACTIVATE PDP CONTEXT ACCEPT 


X 




SN-DATA-PRIORITY ACKNOWLEDGEMENT 


X 




SN-DATA-PRIORITY INFORMATION 


X 




SN-DATA-PRIORITY REQUEST 


X 




SN-MODIFY PDP CONTEXT REOUEST 


X 




SN-MODIFY PDP CONTEXT RESPONSE 


X 




SN-MODIFY PDP CONTEXT AVAILABILITY 


X 




SN-MODIFY PDP CONTEXT USAGE 


X 




SN-UNITDATA 


X (see note) 


X (see note) 


SN-DATA 




X 


SN-DATA TRANSMIT REOUEST 


X 




SN-DATA TRANSMIT RESPONSE 


X 




SN-NOT SUPPORTED 


X 




SN-RECONNECT 


X 




SN-PAGE REOUEST 


X 




SN-PAGE RESPONSE 


X 




SN-END OF DATA 


X 




NOTE: The SwMI and MS use the unacknowledged basic link service for real-time class data. The 
SwMI uses the unacknowledged advanced link service for point-to-multipoint telemetry 
class and background class data. 



The basic link's unacknowledged and acknowledged services are used by the MS and SwMI according to table 28.17. 

Table 28.17: Usage of basic link unacknowledged and acknowledged services 



SN-PDU 


Unacknowledged 


Acknowledged 


SN-ACTIVATE PDP CONTEXT DEMAND 




X 


SN-DEACTIVATE PDP CONTEXT DEMAND 




X 


SN-ACTIVATE PDP CONTEXT ACCEPT 




X 


SN-ACTIVATE PDP CONTEXT REJECT 




X 


SN-DEACTIVATE PDP CONTEXT ACCEPT 




X 


SN-DATA-PRIORITY ACKNOWLEDEGEMENT 




X 


SN-DATA-PRIORITY INFORMATION 




X 


SN-DATA-PRIORITY REQUEST 




X 


SN-MODIFY PDP CONTEXT REOUEST 




X 


SN-MODIFY PDP CONTEXT RESPONSE 




X 


SN-MODIFY PDP CONTEXT AVAILABILITY 




X 


SN-MODIFY PDP CONTEXT USAGE 




X 


SN-DATA TRANSMIT REQUEST 


X (see note 1) 


X (see note 1) 


SN-DATA TRANSMIT RESPONSE 


X 


X (see note 2) 


SN-NOT SUPPORTED 


X (see note 1) 


X (see note 1) 


SN-RECONNECT 




X 


SN-PAGE REQUEST 


X (see note 2) 


X (see note 2) 


SN-PAGE RESPONSE 




X 


SN-END OF DATA 


X (see note 1) 


X (see note 1) 


SN-UNITDATA 


X (see note 3) 




NOTE 1 : The SwMI may use either unacknowledgedor acknowledgedbasic link service and the MS 

shall use acknowledged service. 
NOTE 2: The SwMI may use either acknowledged or unacknowledged basic link service. 
NOTE 3: The SwMI and MS use the unacknowledged basic link service for real-time class data. 
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The lower layer service selection is informed in the protocol model to the lower layers in the corresponding MLE 
service request primitive as the "layer 2 service" parameter. 

28.3.4.2 Logical link setup 

N-PDUs may be sent on acknowledged advanced links, unacknowledged advanced links, and on the unacknowledged 
basic link. Clause 28.3.3a describes how SNDCP assigns particular logical links to PDF contexts. Clause 28.3.3b 
suggests how the MS SNDCP may choose appropriate link parameters. 

The MS shall take the active part in establishing acknowledged advanced links. Up to four advanced links may be used 
by the SNDCP per MS for acknowledged service. The MS shall not establish an advanced link for packet data if there 
are no PDP contexts active. Furthermore the SNDCP entity tracks whether each underlying advanced link is established 
or not. 

The SwMI shall take the active part in establishing unacknowledged advanced links. Up to four advanced links may be 
used by the SNDCP per address for the unacknowledged service, and shall be established when required by the SwMI. 

The unacknowledged basic link does not need to be set up. 

The advanced links are established on the PDCH under the control of SNDCP. Once established, the advanced links 
stay established even when the MS resides on the MCCH but still the MS SNDCP must not use an advanced link 
without requesting the SwMI for permission. 

NOTE: The MS may be involved in circuit mode speech/data in between accessing a PDCH. Then the advanced 
links remain established. 

There are four scenarios listed below where a MS may establish or reset the acknowledged advanced link. 

a) Inbound or outbound data pending - no active advanced link 

A MS shall establish an acknowledged advanced link if the MS has assigned an acknowledged advanced link to the 
relevant PDP context and the assigned acknowledged advanced link is not already active either if the MS has data to 
send or if the MS is notified by an individually-addressed SN-DATA TRANSMIT REQUEST PDU from the SwMI that 
there is outbound data pending. This scenario is the typical scenario where a MS, after successfully activating a PDP 
context, wishes to send data. An example of the establishment of an advanced link in this scenario is presented in 
figures 28.22 to 28.25. 

NOTE 1: The examples described below assume a channel allocation is required to direct a MS from its current 
channel to the PDCH. There may however be occasions where the SwMI decides to allow packet data 
transfer on a common control channel and therefore a channel allocation may not be required. 

NOTE 2: The examples described below shows the MLE as the entity in the SwMI negotiating the establishment of 
advanced links. This is due to there being no information contained within the AL-SETUP PDUs to 
indicate the layer 3 entity in the MS (e.g. SNDCP, SDS, SS etc) which initiated the advanced Unk 
establishment, thus the SwMI MLE entity would be expected to negotiate on behalf of all SwMI layer 3 
entities. The present document does not define how the establishment of advanced links is negotiated 
within the SwMI. 

In figure 28.22 the establishment of an acknowledged advanced link is initiated by the arrival at the MS SNDCP entity 
of a SN-DATA request primitive. While on a common control channel (MCCH or SCCH), the MS will send 
a SN-DATA TRANSMIT REQUEST PDU on the uplink using the acknowledged basic link service. The SwMI will 
respond by sending a SN-DATA TRANSMIT RESPONSE PDU to the MS. The MAC-RESOURCE PDU which 
contains this PDU includes a "Channel Allocation" information element. As no advanced link exists, the SwMI shall 
direct the MS to a suitable PDCH (unless the current channel is suitable). Clause 28.3.4.8 describes the procedure which 
the SwMI should use to choose a suitable PDCH. 

Once on the PDCH, the MS shall establish an advanced link if the advanced link assigned to the PDP context referenced 
in the SN-DATA request or SN-UNITDATA request primitive is not already established. This is achieved through the 
sending of a MLE-CONNECT request primitive to the MLE. 

NOTE 3: If QoS was negotiated by SNDCP during PDP context activation and if the current cell supports QoS 

negotiation during PDP context activation, SNDCP should not provide the "Maximum Transmission rate" 
or "Mean transmission rate" in the MLE-CONNECT request primitive's Quality of Service parameter. 
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Within the MAC-ACCESS PDU used to carry the AL-SETUP PDU on the uplink, the MS may include a "Reservation 
Requirement" for the total number of slots needed to transfer the N-PDU. The MAC -RESOURCE PDU used to carry 
the AL-SETUP PDU response on the downlink may include a "Slot Granting" information element to reserve the 
required number of time slots for the MS on the uplink. The SwMI may also decide to increase the capacity of the 
PDCH (depending on the value of the field "Number of timeslots used per TDMA frame" in the AL-SETUP PDU 
received from the MS) by including in the MAC-RESOURCE PDU a "Channel Allocation" information element with 
"allocation type" = 00 (see clause 23.5.4.2.1 and its clauses of the present document). Once the advanced link has been 
successfully established, the SNDCP service users in the MS and SwMI shall be notified using the SN-QoS indication 
primitive. With the advanced link successfully established, the MS may then begin sending the SN-DATA PDU. 

Refer clause 28.3.4.6 on the channel change protocol. 
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Figure 28.22: Successful advanced link set up, initiated by pending inbound data transfer 

In figure 28.23 the establishment of an acknowledged advanced link is initiated by the arrival at the SwMI SNDCP 
entity of a SN-DATA (or SN-UNITDATA) request primitive. The SwMI shall send a SN-DATA TRANSMIT 
REQUEST PDU on the downlink using the unacknowledged basic link service. The basic link message shall be 
transported using a MAC -RESOURCE PDU which, in this example, contains a "Channel Allocation" information 
element sending the MS to a suitable PDCH. (The procedure for choosing a PDCH is given in clause 28.3.4.) 

Once on the PDCH, if the SN-DATA TRANSMIT REQUEST PDU is individually addressed, the MS shall estabHsh an 
acknowledged advanced link. This is achieved through the sending of a MLE-CONNECT request primitive to the MLE. 
The SwMI may also decide to increase the capacity of the PDCH (depending on the value of the field "Number of 
timeslots used per TDMA frame" in the AL-SETUP PDU received from the MS) by including in the 
MAC-RESOURCE PDU used to carry the AL-SETUP PDU response on the downlink a "Channel Allocation" 
information element with "allocation type"= 00 (see clause 23.5.4.2.1 of the present document). Once an advanced link 
has been successfully established, the SNDCP service users in the MS and SwMI shall be notified using the SN-QoS 
indication primitive. With an advanced link successfully established, the SwMI may then begin sending the SN-DATA 
PDU. 

Refer clause 28.3.4.6 on the channel change protocol. 
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Figure 28.23: Successful advanced link set up, initiated by pending outbound data transfer 

Figure 28.24 shows the case where the establishment of the advanced link fails due to the QoS being offered by the 
SwMI, being lower than the minimum QoS which the MS is willing to accept. 
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Figure 28.24: Failed advanced link setup - too low QoS offered by SwMI 



£75/ 



951 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



Figure 28.25 shows the case where the establishment of the advanced Hnk succeeds, after the MS accepts a lower QoS 
to that originally requested. 



SN-QoS ind 

< 



MS 



SNDCP 



MS 



MLE 



MLE-CONNECT req 



MLE-CONNECT ind 

< 

MLE-CONNECT res 



TL-CONNECT ind 
"^ 



MR 



LLC 



SwMI 
LLC 



SwMI 
MLE 



SwMI 



TL-CONNECT req 



TL-CONNECT res 



AL-SETUP 



AL-SETUP 

< 



AL-SETUP 



TL-CONNECT ind 



TL-CONNECT res 

< 



TL-CONNECT con 



SNDCP 



IVILE-CONNECT ind 



Figure 28.25: Successful advanced link setup - lower QoS accepted 

b) Resetting an active advanced link 

At any time both peer entities, MS and SwMI, may reset an advanced link in order to change QoS parameters. 

NOTE 1 : The SwMI should not reset the advanced link QoS Number of timeslots to a higher value than the last 
received advanced link setup initiated by the MS i.e. the upwards QoS negotiation should be limited to 
the value indicated by the MS. 

NOTE 2: The SwMI may use temporarily less resources than negotiated in the advanced link setup. This is 

indicated in the channel allocation information element and does not thus need advanced link reset. This 
is, however, against the QoS negotiation and should be used only because the SwMI does not temporarily 
have enough resources to fulfil the QoS demand. If the lack of resources is permanent, then the advanced 
link should be reset to a reasonable QoS value. 

NOTE 3: If QoS was negotiated during PDP context activation, the MS or SwMI should change the QoS by 
modifying the PDP context (see clause 28.3.3.5a). 

c) MS returns from READY Temporary Break state after recovering from cell reselection 

The MS SNDCP entity shall re-establish the acknowledged advanced links if the following three conditions are true: 

1 . The MS SNDCP entity is in READY Temporary Break state and receives a MLE-RESUME indication 
primitive from the MLE. 

2. There are SN-DATA PDUs pending for transmission. 

3. The MS does not support advanced link roaming (see clause 28.3.4.4). 

Where a MS SNDCP entity, which is in READY Temporary Break state, receives a MLE-RESUME indication 
primitive from the MLE, it is the responsibility of the MS SNDCP entity to firstly notify the SwMI SNDCP entity that it 
has regained access to the underlying resources (e.g. cell reselection has completed). This notification is carried out by 
sending a SN-RECONNECT PDU on the uplink. 

NOTE: This SN-RECONNECT PDU is of most use when a SwMI is engaged in data transfer on the downlink to 
a MS and the MS switches cell. The SN-RECONNECT PDU is an efficient means by which the SwMI 
SNDCP entity can discover the cell change and re-route data accordingly. 

If the MS has pending SN-DATA or SN-UNITDATA PDUs, the NSAPI value included in the SN-RECONNECT PDU 
should correspond to a PDP context which has pending SN-DATA or SN-UNITDATA PDUs. There is no requirement 
to repeat the SN-RECONNECT PDU with different NSAPI values in those cases where the MS SNDCP posesses more 
than one activated PDP context. 
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The SN-RECONNECT PDU shall be transmitted using the acknowledged basic link service. The SN-RECONNECT 
PDU includes a field "Data to Send" which indicates if the MS has SN-DATA or SN-UNITDATA PDUs awaiting 
transmission. Upon successful transmission of the SN-RECONNECT PDU with "Data to Send" = (thus indicating that 
the MS has no data to send), the MS shall stop the READY timer, shall stop any CONTEXT_READY timers, shall start 
the STANDBY timer and shall enter state STANDBY. Upon successful transmission of the SN-RECONNECT PDU 
with "Data to Send" = 1 (thus indicating that the MS has data to send), the MS shall stop the READY timer, shall stop 
any CONTEXT_READY timers, shall start the STANDBY and RESPONSE_WAIT timers and shall enter state 
RESPONSE-WAITING. On reception of the SN-RECONNECT PDU, the SwMI SNDCP entity shall stop the READY 
timer and any CONTEXT_READY timers, start the STANDBY timer and enter state STANDBY. The SwMI SNDCP 
entity shall check if the MS has indicated within the SN-RECONNECT PDU that it has a pending SN-DATA or 
SN-UNITDATA PDU for transfer on the uplink. The SwMI SNDCP shall also check to see if there is a pending 
SN-DATA PDU or SN-UNITDATA PDU for transfer on the downlink. The message (if any), sent on the downlink by 
the SNDCP entity is shown in table 28.18. 

Table 28.18: Message sent by SwMI in response to SN-RECONNECT from MS 



MS has SN-DATA PDU 

or SN-UNITDATA PDU 

pending 


SwMI has SN-DATA or 
SN-UNITDATA PDU pending 


SwMI response 


No 


No 


no response 


Yes 


No 


SN-DATA TRANSMIT RESPONSE 


No 


Yes 


SN-DATA TRANSMIT REQUEST 


Yes 


Yes 


SN-DATA TRANSMIT RESPONSE 



The SwMI may include a channel allocation in the SN-DATA TRANSMIT REQUEST or SN-DATA TRANSMIT 
RESPONSE PDU, sending the MS to the PDCH. Once on the PDCH the MS shall re-establish the advanced link 
assigned to the relevant PDP context. 

If, while awaiting a response to an SN-RECONNECT PDU, the MS SNDCP receives an 

SN-DATA TRANSMIT RESPONSE PDU with Accept/Reject = or the RESPONSE_WAIT timer expires, the MS 
SNDCP shall stop the RESPONSE_WAIT timer, issue MLE-RELEASE request primitives asking MLE to locally 
disconnect the advanced links and shall enter STANDBY state. 

Figure 28.26 presents the case where the MS has data to send and re-establishes the advanced link once on the PDCH. 

In this case, the MS SNDCP entity is in state READY Temporary Break and receives a MLE-RESUME indication 
primitive from the MLE, thus indicating that access to the communication resources has become available again. It 
sends a SN-RECONNECT PDU to the SwMI SNDCP entity, stops the READY timer, stops all CONTEXT_READY 
timers, starts the STANDBY and RESPONSE_WAIT timers and enters RESPONSE-WAITING state. On reception of 
the SN-RECONNECT PDU, the SwMI stops the READY timer and any CONTEXT_READY timers, starts the 
STANDBY timer and enters STANDBY state. The SwMI on seeing that the MS has indicated in the SN-RECONNECT 
PDU that it has a SN-DATA or SN-UNITDATA PDU awaiting transfer on the uplink, shall respond with a SN-DATA 
TRANSMIT RESPONSE PDU. 

The SN-DATA TRANSMIT RESPONSE PDU may be sent using the acknowledged basic link service or the 
unacknowledged basic link service. Where the MS (after recovering from the radio downlink failure) is on a common 
control channel (MCCH or SCCH), the MAC-RESOURCE PDU which contains this message shall (unless the current 
channel is suitable) include a "Channel Allocation" information element directing the MS either to a single slot PDCH 
or to a multislot PDCH if requested by the resource request information element in the SN-RECONNECT PDU, or by 
choice of the SwMI (see clause 28.3.4.8). On transmission of the SN-DATA TRANSMIT RESPONSE PDU, the SwMI 
shall stop the STANDBY timer, start the READY timer and enter READY state. The SwMI may start a 
CONTEXT_READY timer (see clause 28.2.6.2). On reception of the SN-DATA TRANSMIT RESPONSE PDU, the 
MS shall stop the STANDBY and RESPONSE_WAIT timers, start the READY timer, shall, if supported, start the 
CONTEXT-READY timer for that PDP context, and shall enter READY state. 
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On the PDCH, the MS must re-establish the advanced links assigned to the PDP contexts which have data waiting to be 
sent. This is achieved through the sending of MLE-CONNECT request primitives to the MLE. Within the 
MAC-ACCESS PDU used to carry the AL-SETUP PDU on the uplink, the MS may include a "Reservation Request" 
information element for the total number of slots needed to transfer any pending data. The MAC-RESOURCE PDU 
used to carry the AL-SETUP PDU response on the downlink may include a "Slot Granting" information element to 
reserve time slots for the MS on the uplink. The MAC-RESOURCE PDU may also decide to increase the capacity of 
the PDCH (depending on the value of the field "Number of timeslots used per TDMA frame" in the AL-SETUP PDU 
received from the MS) by including a "Channel Allocation" information element with "allocation type"= 00 (see 
clause 23.5.4.2.1 and its clauses of the present document). 
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Figure 28.26: Advanced link set up after a radio downlinit failure, with MS in READY state 

d) Failure to send a N-PDU 

After receiving an MLE-REPORT indication primitive indicating failure sending a N-PDU the MS or SwMI shall reset 
the relevant advanced link. This reset is required by the SNDCP user application and compression mechanisms 
expecting a reliable link. This link reset is required when even a single N-PDU is lost. This applies for both the MS and 
SwMI i.e. the SwMI should reset the relevant advanced link when it recognizes failure sending a N-PDU. 

Where the MS SNDCP entity receives a SN-END OF DATA PDU from the SwMI (effectively moving the MS off the 
PDCH), prior to reception of a MLE-REPORT indicating whether the transmission of a SN-DATA or 
SN-UNITDATA PDU was successful or not, then the MS shall reset the assigned advanced link (SN-DATA PDU only) 
and notify the service user, with a SN-DELIVERY indication primitive, of the failure to send the SN-DATA or 
SN-UNITDATA PDU. This scenario is shown in figure 28.27. 
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In the example, a MS passes a SN-DATA PDU to the lower layers. It then receives a SN-END OF DATA from the peer 
SNDCP entity in the SwMI. As the MS SNDCP has not yet had confirmation (in the form of a MLE-REPORT 
indication primitive) that the previous SN-DATA was successfully transmitted, it resets the assigned advanced link. 
Before sending the AL-SETUP PDU with a reason "Reset", the MS sends SN-DATA TRANSMIT REQUEST PDU to 
the SwMI in order to get to the PDCH where it can re-establish the assigned advanced link. 
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Figure 28.27: Resetting advanced linl< after reception of SN-END OF DATA PDU 
prior to completing transfer of previous SN-DATA PDU 

e) Return from circuit mode call 

In an alternating voice and data communication a MS can be offered a group call on the PDCH and the MS may accept 
the group call. The MS may want to return to the interrupted PDCH communication and the MS SNDCP entity may 
notify the SwMI SNDCP entity that it is again available. In case the MS has no data to send this notification is carried 
out by sending a SN-RECONNECT PDU on the uplink; if the MS has data to send then it is done with SN-TRANSMIT 
REQUEST PDU when the SERVICE_CHANGE timer is inactive. 

If the MS supports and needs to reconnect advanced link after return from the voice call, then clause 28.3.4.4 is 
applicable. 

28.3.4.3 Logical Link disconnection 

An acknowledged advanced link is disconnected before the deactivation of the last PDP context assigned to that 
advanced link, as shown in figure 28.28. The disconnection is triggered by the MS. In case of MS originated PDP 
context deactivation procedure (e.g. the SN-SAP user has triggered PDP context deactivation by issuing SN-NSAPI 
DEALLOC request primitive), the MS shall first disconnect the advanced link explicitly and after advanced link 
disconnection start the actual PDP context deactivation procedure as defined in clause 28.3.3.6.1. In case of SwMI 
originated PDP context deactivation procedure, the MS shall trigger advanced link disconnection in reception of a 
SN-DEACTIVATE PDP CONTEXT DEMAND PDU from the SwMI and shall not respond by a SN-DEACTIVATE 
PDP CONTEXT ACCEPT PDU until advanced link is explicitly disconnected. 

NOTE 1 : If the MS has initiated the advanced link disconnection, it should not accept packet data service any more 
for PDP contexts assigned to that link. 
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NOTE 2: In case the STANDBY timer expires, the advanced Hnks may be exceptionally released implicitly without 
sending AL-DISC PDUs. 
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Figure 28.28: Disconnecting advanced linl< before the last PDP context deactivation 



28.3.4.4 



Advanced link reconnection 



In an attempt to improve the performance of packet data transfer during cell reselection, a SwMI may allow a MS to 
maintain its advanced link as it roams between cells. The ability for a MS to continue using an advanced link on a new 
cell with all parameters, variables and timers carried from the previous cell is called advanced link roaming. It is 
optional for a MS or SwMI to support advanced link roaming. Advanced link roaming is initiated by the MS, by 
requesting the reconnection of an advanced link on the new cell. The SwMI shall respond to this request by indicating if 
the request has been accepted or rejected. The reconnection of an advanced link shall only be initiated by the MS. The 
MS SNDCP entity shall only attempt to reconnect an advanced link if the following two events have occurred: 

1 . The MS SNDCP entity has transmitted a SN-RECONNECT PDU after successful cell handover; 

2. The MS has received a SN-DATA TRANSMIT RESPONSE PDU accepting the request or a SN-DATA 
TRANSMIT REQUEST PDU in response to the SN-RECONNECT PDU and moved to the PDCH. 

If both the above are true and the MS supports advanced link roaming, then the MS SNDCP entity may issue a 
MLE-RECONNECT request primitive to the MLE which shall be forwarded to the LLC as a TL-RECONNECT request 
primitive. The LLC shall build an AL-RECONNECT PDU with reconnect report value "propose" and send it to the 
SwMI. If the SwMI recognizes the AL-RECONNECT PDU it shall respond with an AL-RECONNECT PDU. In this 
PDU the SwMI shall indicate if it supports advanced link roaming or not by the reconnect report value "accept" or 
"reject" respectively. Reception of the AL-RECONNECT PDU from the SwMI shall resuh in the MS LLC passing a 
TL-RECONNECT confirm primitive to the MLE and in turn a MLE-RECONNECT confirm primitive being passed to 
the SNDCP entity. Based on the response from the SwMI, the MS SNDCP entity at this point will know if the advanced 
link has been successfully reconnected or not. Where multiple acknowledged advanced links are in use, the MS SNDCP 
may attempt to reconnect each by issuing successive MLE-RECONNECT request primitives to the MLE. The MS 
SNDCP does not need to await the arrival of a MLE-RECONNECTconfirm primitive for one advanced link before 
sending an MLE-RECONNECT request primitive for another advanced link. 

Refer to clause 28.3.4.6 on the channel change protocol. 
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Figure 28.29 presents the case where both the MS and SwMI support advanced link roaming and where the MS is in 
ready state with data to transmit when the cell reselection procedures begin. 
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NOTE: Each nnessage number in the figure above has a number associated with it which corresponds to the 
numbers of the bullet points in the description below. 

Figure 28.29: Successfully reconnecting an advanced link after cell reselection. 
Both MS and SwMI support advanced link roaming 

1) Signal quality begins to fall -> MLE decides to switch cell. 

2) MLE sends MLE-BREAK indication primitive to SNDCP. 

3) As the MS supports advanced link roaming, the MLE will not disconnect the advanced links (i.e. a 
TL-RELEASE request primitive is not sent to the LLC). The MS SNDCP enters the READY-temporary break 
state from the READY state. 

4) MLE sends TL-SELECT request primitive to the LLC requesting the MAC to switch to the main carrier of the 
new cell. 

5) LLC forwards this as a TMC-SELECT request primitive to the MAC (not shown). 

6) The MAC switches to the MCCH of the new cell and issues a TMC-SELECT confirm primitive to the LLC 
which is then passed to the MLE as a TL-SELECT confirm primitive. 

7) MM performs registration (Vh-D) and authentication if required (not shown). 
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8) MLE sends MLE-RESUME indication primitive to SNDCP. 

9) SNDCP sends a SN-RECONNECT PDU to the SwMI. If there is data awaiting transmission in the SNDCP 
buffer, or if the SNDCP entity is aware that a partially transmitted TL-SDU is in the LLC buffers (i.e. one 
which has not yet been fully transmitted or one for which an acknowledgement has not yet been received from 
the peer entity), then the "Data to Send" field in the SN-RECONNECT PDU will be set to True else the "Data 
to Send" field will be set to False. In this case the Data to Send field is set to True. 

10) The MS SNDCP entity enters RESPONSE-WAITING state, stops the READY timer, stops all 
CONTEXT_READY timers and starts the STANDBY and RESPONSE-WAIT timers. 

1 1) On reception of a SN-DATA TRANSMIT RESPONSE PDU from the SwMI, the MS shall switch to the 
PDCH and enter READY state. 

NOTE 1 : If for some reason the MS does not receive a SN-DATA TRANSMIT RESPONSE PDU prior to the 

RESPONSE_WAITING timer expires or if a SN-DATA TRANSMIT RESPONSE PDU is received with 
Accept/Reject = (i.e. requested is rejected), then SNDCP should attempt to initiate local disconnection 
of the advanced links. 

12) SNDCP requests that an acknowledged advanced link is reconnected by passing MLE-RECONNECT request 
primitive to the MLE which in turn passes a TL-RECONNECT request primitive to the LLC. The LLC sends 
an AL-RECONNECT PDU with the reconnect report set to "propose" to the SwMI. 

13) The SwMI responds with an AL-RECONNECT PDU, indicating that advanced link roaming is supported by 
setting the reconnect report set to "accept". The MS may now continue transmitting or receiving LLC 
segments for that advanced link from where it left off on the previous cell. If SNDCP possesses activated PDP 
contexts assigned to other acknowledged advanced links, the MS SNDCP may attempt to reconnect those links 
by issuing further MLE-RECONNECT request primitives (not shown in figure 28.29). 
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Figure 28.30 presents the case where the MS attempts to reconnect an advanced link on the new cell, but the SwMI 
rejects this request. 
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Figure 28.30: Failure to reconnect thie advanced linl< after cell reselection. 
SwMI does not support advanced link roaming 

1) Signal quality begins to fall -> MLE decides to switch cell. 

2) MLE sends MLE-BREAK indication primitive to SNDCP. 

3) As the MS supports advanced link roaming, the MLE will not disconnect the advanced links (i.e. no 
TL-RELEASE request primitives are sent to the LLC). The MS SNDCP enters the READY-temporary break 
state from the READY state. 
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4) MLE sends TL-SELECT request primitive to the LLC requesting the MAC to switch to the main carrier of the 
new cell. 

5) LLC forwards this as a TMC-SELECT request primitive to the MAC (not shown). 

6) The MAC switches to the MCCH of the new cell and issues TMC-SELECT confirm primitive to the LLC 
which is then passed to the MLE as a TL-SELECT confirm primitive. 

7) MM performs registration (Vh-D) and authentication if required (not shown). 

8) MLE sends MLE-RESUME indication primitive to SNDCP. 

9) SNDCP shall send a SN-RECONNECT PDU to the SwMI. If there is data awaiting transmission in the 
SNDCP buffer, or if the SNDCP entity is aware that a partially transmitted TL-SDU is in the LLC buffers 
(i.e. one which has not yet been fully transmitted or one for which an acknowledgement has not yet been 
received from the peer entity), then the "Data to Send" field in the SN-RECONNECT PDU will be set to True. 
Else the "Data to Send" field will be set to False. In this case it is assumed the Data to Send field is set to True. 

10) The MS SNDCP entity enters RESPONSE-WAITING state, stops the READY timer, stops all 
CONTEXT_READY timers and starts the STANDBY and RESPONSE-WAIT timers. 

1 1) On reception of a SN-DATA TRANSMIT RESPONSE PDU from the SwMI, the MS shall switch to the 
PDCH and enter READY state. 

NOTE 2: If for some reason the MS does not receive a SN-DATA TRANSMIT RESPONSE PDU prior to the 

RESPONSE_WAITING timer expires or if a SN-DATA TRANSMIT RESPONSE PDU is received with 
Accept/Reject = (i.e. requested is rejected), then SNDCP should attempt to initiate local disconnection 
of the advanced hnk. 

12) SNDCP requests that the advanced link is reconnected by passing MLE-RECONNECT request primitive to 
the MLE which in turn passes a TL-RECONNECT request primitive to the LLC. The LLC sends an 
AL-RECONNECT PDU to the SwMI with the reconnect report set to "propose". If SNDCP possesses 

PDP contexts assigned to other acknowledged advanced links, the MS may also attempt to reconnect each of 
those links by issuing further MLE-RECONNECT request primitives (not shown in figure 28.30). 

13) The SwMI responds with an AL-RECONNECT PDU, indicating that advanced link roaming is not supported 
for the indicated link by setting the reconnect report to "reject". 

14) In order to reset the LLC advanced link state machine, the SNDCP entity shall pass a MLE-RELEASE request 
primitive to the MLE which in turn passes a TL-RELEASE request primitive to the LLC. 

15) The SNDCP entity now requests that the advanced link is reset by passing MLE-CONNECT request primitive 
to the MLE which in turn passes a TL-CONNECT request primitive to the LLC. The LLC sends an 
AL-SETUP PDU to the SwMI. 

16) The SwMI responds with an AL-SETUP PDU indicating the resetting of the advanced link. The MS may now 
begin transmitting or receiving packet data. 

28.3.4.5 Releasing the advanced link 

Where a MS does support advanced link roaming, and where the SNDCP entity receives a MLE-BREAK indication 
primitive while in standby state, then on reception of a corresponding MLE-RESUME indication primitive, the SNDCP 
entity shall locally disconnect all existing advanced links by issuing MLE-DISCONNECT request primitives to the 
MLE. 

28.3.4.6 Physical channel handling 

In the TETRA protocol model MAC layer may request upper layers to decide whether a physical channel change is 
performed as proposed by BS to support a network layer service. This allows application layers to negotiate which 
service is selected when there is a conflict between various services e.g. ongoing speech service and packet data service. 
The details of the negotiation are outside the scope of the present document. The MLE layer provides the channel 
change request to the SNDCP as a "channel change response required" parameter set to "true" in conjunction with a 
"Channel change handle" parameter, refer to clause 17.3.5. 
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If the channel change is acceptable on all services point of view the SNDCP shall respond to that request by issuing 
an MLE-CONFIGURE request primitive containing a "channel change accepted" parameter set to "accept". In the 
SNDCP protocol descriptions this is implied by requirements such as "the MS shall switch to the PDCH". 

In the special case that the "channel change response required" parameter set to "true" is delivered to the MS SNDCP in 
an MLE-UNITDATA indication primitive that contains a group addressed SN-END OF DATA PDU when the READY 
timer is active, the MS SNDCP shall respond by issuing an MLE-CONFIGURE request primitive containing a "channel 
change accepted" parameter set to "ignore". 

In all other cases where the channel change is not acceptable, the MS SNDCP shall respond to an MLE primitive 
containing a "channel change response required" parameter set to "true" by issuing an MLE-CONFIGURE request 
primitive with the "channel change accepted" parameter set to "reject". 

28.3.4.7 Loss of Radio Resource 

On reception of an MLE-CONFIGURE indication primitive advising "loss of radio resources": 

• if data priority is supported by the MS, the MS SNDCP shall inform MLE that the MS default data priority is 
"not applicable" using the MLE-CONFIGURE request primitive; 

• if there is data awaiting transmission, including where the MS SNDCP entity is aware that a partially 
transmitted N-PDU is in the LLC buffers (i.e. one which has not yet been fully transmitted or one for which an 
acknowledgement has not yet been received from the peer entity), then the MS SNDCP entity shall send to the 
SwMI a SN-RECONNECT PDU with the field "Data to Send" set to 1, shall start the RESPONSE_WAIT 
timer and shall enter the READY-temporary break state; 

• if there is no data awaiting transmission, the MS SNDCP entity shall send to the SwMI a 
SN-RECONNECT PDU with the field "Data to Send" set to 0, shall stop the READY timer and any 
CONTEXT_READY timers, start the STANDBY timer and enter STANDBY state. 

NOTE: The "loss of radio resources" indication means that the PDCH has failed, and that the MS has been moved 
back to the MCCH. The MS attempts to transmit the SN-RECONNECT PDU on the MCCH. 

28.3.4.8 Selection of physical channel 

When an MS indicates to the SwMI that it wishes to transmit or receive SN-DATA or SN-UNITDATA PDUs by 
sending an SN-DATA TRANSMIT REQUEST, SN-PAGE RESPONSE or SN-RECONNECT PDU on the uplink, or if 
the SwMI wishes to transmit SN-DATA or SN-UNITDATA PDUs to an MS, the SwMI should assign the MS to a 
suitable PDCH if the current physical channel is not suitable. This also applies if the MS-MLE requests a change to a 
new assigned channel when the MS already using a PDCH. 

The SwMI chooses a suitable physical channel as follows: 

• if QoS was not negotiated for this PDP context, SNDCP is not in the READY state and a 7t/4-DQPSK 
multislot channel was not indicated in the resource request information element of the 

SN-DATA TRANSMIT REQUEST, SN-PAGE RESPONSE or SN-RECONNECT PDU, the SwMI shall 
choose a single-slot 7t/4-DQPSK PDCH; or 

• if a 7t/4-DQPSK single slot channel was indicated in the resource request information element of 
SN-DATA TRANSMIT REQUEST, SN-PAGE RESPONSE or SN-RECONNECT PDU,the SwMI shall 
choose a single slot 7t/4-DQPSK PDCH; or 

• if a 7t/4-DQPSK multislot channel was indicated in the resource request information element of 
SN-DATA TRANSMIT REQUEST, SN-PAGE RESPONSE or SN-RECONNECT PDU, the SwMI shall 
choose a 7t/4-DQPSK PDCH, and may choose a multislot PDCH; or 
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• if QoS was negotiated for this PDP context and a resource request was not included in the 

SN-DATA-TRANSMIT REQUEST, SN-PAGE RESPONSE or SN-RECONNECT PDU, or if SNDCP is in 
the READY state, the SwMI should choose a physical channel within the MS's declared capabilities which can 
satisfy the implicit or explicit QoS requirements in the SN-DATA TRANSMIT REQUEST, 
SN-PAGE RESPONSE or SN-RECONNECT PDU, and the QoS requirements of all PDP contexts with active 
CONTEXT_READY timers. The SwMI should take into account any advice from the MLE about which 
channels the MS can currently use that is included in the U-SECTOR ADVICE or U-CHANNEL ADVICE 
PDU (which may accompany the SN-DATA TRANSMIT REQUEST, SN-PAGE RESPONSE or 
SN-RECONNECT PDUs) or in the U-CHANNEL REQUEST PDU. 

NOTE: SwMI can send an MS to a D8PSK or QAM channel only if the MS included QoS in a PDP context 
activation or modification request. 

28.3.5 Packet Data transmission and reception procedures 

This clause describes the procedures within SNDCP for transmitting and receiving packet data. Acknowledged and 
unacknowledged services are available for packet data transfer. This clause also defines compression techniques which 
may be used during data transfer as a way of improving efficiency. 

28.3.5.1 Acknowledged data service 

The basic setting for sending N-PDUs between MS and SwMI is to use acknowledged service. 

A scenario illustrating acknowledged data sending from SwMI to MS is shown in figure 28.31 (window size 1). Each 
numbered step is explained in the following list. 
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Figure 28.31 : Acknowledged service, data from SwIUII to lUIS 
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1 . The S wMI SNDCP receives the first SN-DATA request primitive. 

2. The SwMI SNDCP sends SN-DATA TRANSMIT REQUEST PDU. The request is sent by using the 
acknowledged or unacknowledged service (basic link) and the MAC-RESOURCE PDU contains a "Channel 
Allocation" information element sending the MS to a PDCH (the method of choosing the PDCH is given in 
clause 28.3.4.8). On transmission of the SN-DATA TRANSMIT REQUEST PDU, the SwMI stops the 
STANDBY timer, starts the READY timer, may start a CONTEXT_READY timer (see clause 28.2.6.2) and 
enters state READY. On reception of the SN-DATA TRANSMIT REQUEST PDU, the MS stops the 
STANDBY timer, starts the READY timer, starts the CONTEXT_READY timer for the PDP context 
referenced by the NSAPI parameter in the SN-DATA request primitive, and enters state READY. 

3. The SwMI SNDCP receives the second SN-DATA request primitive. 

4. The first N-PDU is sent to the MS by issuing SN-DATA PDU. On reception of an indication from the MLE, in 
the form of an MLE-REPORT indication primitive, that the SN-DATA PDU was successfully transmitted by 
the lower layers, the SwMI SNDCP entity shall restart the READY timer and the CONTEXT_READY timer 
(if used). At the MS the reception of the SN-DATA PDU shall result in the READY timer and, if supported, 
the CONTEXT_READY timer being restarted. 

5. After receiving the first SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing a 
SN-DATA indication primitive 

6. After receiving acknowledgement that the first SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

7. The second N-PDU is sent to the MS by issuing SN-DATA PDU. The READY timer is restarted in the SwMI 
SNDCP and in the MS SNDCP. The relevant CONTEXT_READY timer is restarted in the MS SNDCP and, if 
used, in the SwMI SNDCP. 

8. After receiving the second SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing 
a SN-DATA indication primitive. 

9. After receiving acknowledgement that the second SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

10. The SwMI SNDCP receives the third SN-DATA request primitive. 

11. The third N-PDU is sent to the MS by issuing SN-DATA PDU. The READY timer is re-started in the SwMI 
SNDCP and in the MS SNDCP. The relevant CONTEXT_READY timer is restarted in the MS SNDCP and, if 
used, in the SwMI SNDCP. 

12. After receiving the third SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing 
SN-DATA indication primitive. 

13. After receiving acknowledgement that the third SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

14. The READY timer expires in the SwMI SNDCP and it issues SN-END OF DATA PDU, including channel 
allocation, to the MS, starts the STANDBY timer and enters STANDBY state. The MS SNDCP receives 
SN-END OF DATA PDU, stops its READY timer and any CONTEXT_READY timers, starts the STANDBY 
timer and enters STANDBY state on the indicated channel. 

NOTE: If the existing advanced links do not include the advanced link which the MS has assigned to this PDP 
context, the MS may setup the assigned advanced link following receipt of the SN-DATA TRANSMIT 
REQUEST PDU from the SwMI. The SwMI may then switch to using this new advanced link if it thinks 
this is the most suitable for carrying data for this PDP context. 



£75/ 



963 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



A scenario illustrating acknowledged data sending from the SwMI to MS over an advanced link having TL-SDU 
window size of 3 is shown in figure 28.32. Each numbered step is explained in the following list. 



MS 



SNDCP 



.10. SN-DATA 



,13. SN-DATAind 
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15. SN-DATA 



SwIVII 



SNDCP 




22. SN END OF DATA 

(MAC Resource includes 'Channel Allocation Element') 



^ 1 . SN-DATA r eq 
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17. SN-Delivery ind 



19. SN-Delivery ind 
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Figure 28.32: Acknowledged service on advanced linl< having TL-SDU window size 3, 

data from SwIVII to MS 

1 . The SwMI SNDCP receives the first SN-DATA request primitive. 

2. The SwMI SNDCP sends SN-DATA TRANSMIT REQUEST PDU. The request is sent by using the 
acknowledged or unacknowledged service (basic link) and the MAC-RESOURCE PDU contains a "Channel 
Allocation" information element sending the MS to a PDCH (the method of choosing the PDCH is given in 
clause 28.3.4.8). On transmission of the SN-DATA TRANSMIT REQUEST PDU, the SwMI stops the 
STANDBY timer, starts the READY timer and enters state READY. On reception of the SN-DATA 
TRANSMIT REQUEST PDU, the MS stops the STANDBY timer, starts the READY timer, starts the 
CONTEXT_READY timer for the PDP context referenced by the NSAPI parameter in the SN-DATA request 
primitive, and enters state READY. 

3. The SwMI SNDCP receives the second SN-DATA request primitive. 

4. The first N-PDU is sent to the MS by issuing SN-DATA PDU. On reception of an indication from the MLE, in 
the form of an MLE-REPORT indication primitive, that the SN-DATA PDU was successfully transmitted by 
the lower layers, the SwMI SNDCP entity shall restart the READY timer. At the MS the reception of the 
SN-DATA PDU shall result in the READY timer and, if supported, the CONTEXT_READY timer being 
restarted. 

5. The second N-PDU is sent (immediately after the first one) to the MS by issuing SN-DATA PDU as the 
sliding TL-SDU window allows it. 

6. The SwMI SNDCP receives the third SN-DATA request primitive. 

7. The third N-PDU is sent to the MS by issuing SN-DATA PDU as the shding TL-SDU window allows it. 
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8. The SwMI SNDCP receives the fourth SN-DATA request primitive. The N-PDU cannot be sent to the MS yet 
as the sliding window is full. 

9. The SwMI SNDCP receives the fifth SN-DATA request primitive. The N-PDU cannot be sent to the MS yet 
as the sliding window is full. 

10. After receiving the first SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing a 
SN-DATA indication primitive. 

11. After receiving acknowledgement that the first SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

12. The fourth N-PDU is sent to the MS by issuing SN-DATA PDU as the TL-SDU window now allows it (since 
the first N-PDU was transmitted correctly and thus the sliding TL-SDU window may advance). 

13. After receiving the second SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing a 
SN-DATA indication primitive. 

14. After receiving acknowledgement that the second SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

15. The fifth N-PDU is sent to the MS by issuing SN-DATA PDU as the TL-SDU window now allows it (since 
the second N-PDU was transmitted correctly and thus the sliding TL-SDU window may advance). 

16. After receiving the third SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing a 
SN-DATA indication primitive. 

17. After receiving acknowledgement that the third SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. If the SNDCP had more N-PDUs for the MS 
one PDU could be sent now since the sliding window would allow it. However, in this example there is no 
more data to send. 

18. After receiving the fourth SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing a 
SN-DATA indication primitive. 

19. After receiving acknowledgement that the fourth SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

20. After receiving the fifth SN-DATA PDU the MS SNDCP passes the N-PDU to the higher layer by issuing a 
SN-DATA indication primitive. 

21. After receiving acknowledgement that the fifth SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

22. The READY timer expires in the SwMI SNDCP and it issues SN-END OF DATA PDU, including channel 
allocation, to the MS, starts the STANDBY timer and enters STANDBY state. The MS SNDCP receives 
SN-END OF DATA PDU, stops its READY timer, starts the STANDBY timer and enters STANDBY state on 
the indicated channel. 
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A scenario illustrating acknowledged data sending from MS to SwMI is shown in figure 28.33. Each numbered step is 
explained in the following list. 
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Figure 28.33: Acknowledged service, data from IVIS to SwIVII 

1 . The MS SNDCP receives the first SN-DATA request primitive. 

2. The MS SNDCP sends SN-DATA TRANSMIT REQUEST PDU. The request is sent by using acknowledged 
service (basic link). On sending the SN-DATA TRANSMIT REQUEST PDU, the MS SNDCP entity, starts 
the RESPONSE_WAIT timer and enters RESPONSE-WAITING state. 

3. The MS SNDCP receives the second SN-DATA request primitive. 

4. The SwMI SNDCP sends SN-DATA TRANSMIT RESPONSE PDU. The response is sent by using the 
acknowledged or unacknowledged service (basic link) and the MAC -level MAC-RESOURCE PDU contains 
channel allocation information element commanding the MS to PDCH. On transmission of the SN-DATA 
TRANSMIT RESPONSE PDU, the SwMI stops the STANDBY timer, starts the READY timer, may start a 
CONTEXT_READY timer (see clause 28.2.6.2) and enters state READY. On reception of the SN-DATA 
TRANSMIT RESPONSE PDU, the MS stops the STANDBY and RESPONSE_WAIT timers, starts the 
READY timer and the relevant CONTEXT_READY timer, and enters state READY. 

5. The MS SNDCP receives the third SN-DATA request primitive. 

6. The first N-PDU is sent to the SwMI by issuing SN-DATA PDU. On reception of an indication from the MLE, 
in the form of an MLE-REPORT indication primitive, that the SN_DATA PDU was successfully transmitted 
by the lower layers, the MS SNDCP entity shall restart the READY timer and shall, if supported, restart the 
relevant CONTEXT_READY timer. At the SwMI the reception of the SN-DATA PDU shall result in the 
READY timer being restarted and, if used, the CONTEXT_READY timer is restarted. 

7. After receiving acknowledgement that the first SN-DATA PDU was successfully sent to the SwMI, the MS 
sends SN-DELIVERY indication primitive to the higher layer. 

8. After receiving the first SN-DATA PDU, the SwMI SNDCP passes the N-PDU to the higher layer by issuing 
SN-DATA indication primitive. 
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9. The second N-PDU is sent to the SwMI by issuing SN-DATA PDU. The READY timer is restarted in the MS 
SNDCP and in the SwMl SNDCP. The relevant CONTEXT_READY timer is restarted in the MS SNDCP 
and, if used, in the SwMI SNDCP. If scheduled access was agreed with the SwMI for this PDP context during 
PDP context activation, the MS SNDCP indicates that the SN-PDU is scheduled and includes the value of the 
maximum schedule period for this PDP context in the MLE-UNITDATA request primitives carrying this and 
all subsequent SN-DATA PDUs for this PDP context. 

10. After receiving acknowledgement that the second SN-DATA PDU was successfully sent to the SwMI, the MS 
sends SN-DELIVERY indication primitive to the higher layer. 

11. The third N-PDU is sent to the SwMI by issuing SN-DATA PDU. The READY timer is re-started in the MS 
SNDCP and in the SwMI SNDCP. The relevant CONTEXT_READY timer is restarted in the MS SNDCP 
and, if used, in the SwMI SNDCP. 

12. After receiving the second SN-DATA PDU, the SwMI SNDCP passes the N-PDU to the higher layer by 
issuing SN-DATA indication primitive. 

13. After receiving acknowledgement that the third SN-DATA PDU was successfully sent to the SwMI, the MS 
sends SN-DELIVERY indication primitive to the higher layer. 

14. After receiving the third SN-DATA PDU the SwMI SNDCP passes the N-PDU to the higher layer by issuing 
SN-DATA indication primitive. 

15. The READY timer expires in the SwMI SNDCP and it issues SN-END OF DATA PDU, including channel 
allocation, to the MS, starts the STANDBY timer and enters STANDBY state. The MS SNDCP receives 
SN-END OF DATA PDU, stops its READY timer and any CONTEXT_READY timers, starts the STANDBY 
timer and enters STANDBY state in the allocated channel. 

A scenario illustrating acknowledged data sending from MS to SwMI and from SwMI to MS is shown in figure 28.34. 
Each numbered step is explained in the following list. 
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Figure 28.34: Acknowledged service, data from IVIS to SwIVII and from SwIVII to IVIS 

1 to 14These steps as in figure 28.33 "acknowledged service, data from MS to SwMI". 

15. The SwMI SNDCP receives the first (and only one in this scenario) SN-DATA request primitive. 
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16. The first N-PDU is sent to the MS by issuing SN-DATA PDU. On reception of an indication from the MLE, in 
the form of an MLE-REPORT indication primitive, that the SN_DATA PDU was successfully transmitted by 
the lower layers, the SwMI SNDCP entity shall restart the READY timer and, if used, the 
CONTEXT_READY timer. At the MS, the reception of the SN-DATA PDU shall result in the READY timer 
being restarted. The MS SNDCP also starts the CONTEXT_READY timer referenced by the NS API in the 
SN-DATA PDU. 

17. After receiving the first SN-DATA PDU, the MS SNDCP passes the N-PDU to the higher layer by issuing 
SN-DATA indication primitive. 

18. After receiving acknowledgement that the first SN-DATA PDU was successfully sent to the MS, the SwMI 
sends SN-DELIVERY indication primitive to the higher layer. 

19. The READY timer expires in the SwMI SNDCP and it issues SN-END OF DATA PDU, including channel 
allocation, to the MS, starts the STANDBY timer and enters STANDBY state. The MS SNDCP receives 
SN-END OF DATA PDU, stops its READY timer, stops all CONTEXT_READY timers, starts the 
STANDBY timer and enters STANDBY state on the allocated channel. 

A scenario illustrating Ready timer expiry in the MS is shown in figure 28.35. Each numbered step is explained in the 
following list. 
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Figure 28.35: Acknowledged service, READY timer expiry in the IVIS 

1 to 14These steps are the same as in figure 28.33 "acknowledged service, data from MS to SwMI". 

15. The SwMI SNDCP receives the first (and only one in this scenario) SN-DATA request primitive. 

16. The first N-PDU is sent to the MS by issuing SN-DATA PDU. The READY timer and, if used, the 
CONTEXT_READY timer are started in the SwMI SNDCP (when the SN-DATA PDU is successfully sent) 
and in the MS SNDCP (when the SN-DATA PDU is received). The relevant CONTEXT_READY timer is 
also started in the MS SNDCP when the SN-DATA PDU is received. 

17. After receiving the first SN-DATA PDU the MS SNDCP passes N-PDU to the higher layer by issuing 
SN-DATA indication primitive. 
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18. After receiving acknowledgement that the first SN-DATA PDU was successfully sent to the MS the SwMI 
sends SN-Delivery indication primitive to the higher layer. 

19. The READY timer expires in the MS SNDCP and it issues SN-END OF DATA PDU to the SwMl. The MS 
restarts the READY timer. 

20. After receiving SN-END OF DATA PDU from the MS SNDCP the SwMI SNDCP issues SN-END OF DATA 
PDU, including channel allocation, to the MS, starts the STANDBY timer and enters STANDBY state. The 
MS SNDCP receives SN-END OF DATA PDU, stops its READY timer, starts the STANDBY timer and 
enters STANDBY state on the allocated channel. 

A scenario illustrating RESPONSE_WAlT timer expiry in the MS is shown in figure 28.36. Each numbered step is 
explained in the following list. 



MS 



SNDCP 



1 . SN-Data request 



3. SN-Data request 
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10. SN-Data Transmit Request 
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V 



1 1 . SN-Data Transmit Response 
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NOTE: The present document does not define the number of SN-DATA and SN-UNITDATA request primitives 
which may be buffered in the MS while the RESPONSE_WAIT timer is active. 

Figure 28.36: Acknowledged service, RESPONSE_WAIT timer expiry in the IVIS 

1. The service user issues a SN-DATA request primitive to the MS SNDCP entity. 

2. The MS SNDCP entity transmits a SN-DATA TRANSMIT REQUEST PDU, starts the RESPONSE_WAIT 
timer and enters RESPONSE-WAITING state. 

3. The service user issues a second SN-DATA request primitive to the MS SNDCP entity. 

4. The service user issues a third SN-DATA request primitive to the MS SNDCP entity. 
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5. The RESPONSE_WAIT timer expires. The MS SNDCP entity enters STANDBY state. 

6. The MS SNDCP entity issues a SN-DELIVERY indication primitive to the service user, giving notification 
that the SN-DATA request primitive received in 1) has failed. 

7. The MS SNDCP entity issues a SN-DELIVERY indication primitive to the service user, giving notification 
that the SN-DATA request primitive received in 3) has failed. 

8. The MS SNDCP entity issues a SN-DELIVERY indication primitive to the service user, giving notification 
that the SN-DATA request primitive received in 4) has failed. 

9. The service user issues a new SN-DATA request primitive to the MS SNDCP entity. 

10. The MS SNDCP entity transmits a SN-DATA TRANSMIT REQUEST PDU, starts the RESPONSE_WAIT 
timer and enters RESPONSE- WAITING state. 

n . The MS SNDCP entity receives a SN-DATA TRANSMIT RESPONSE PDU (with Accept/Reject = 1). The 
RESPONSE_WAIT and STANDBY timers are stopped and the READY state is entered. The MS may now 
send the N-PDUs received from the service user, using SN-DATA PDUs as described in the previous 
examples. 

A scenario illustrating SwMI rejecting a request from the MS is shown in figure 28.37. Each numbered step is explained 
in the following list. 
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Figure 28.37: Acknowledged service, SwIVII rejects request 

1. The service user issues a SN-DATA request primitive to the MS SNDCP entity. 

2. The MS SNDCP entity transmits a SN-DATA TRANSMIT REQUEST PDU, starts the RESPONSE_WAIT 
timer and enters RESPONSE-WAITING state. 

3. Due to heavy system loading the SwMI rejects the request. The SwMI delivers a SN-DATA TRANSMIT 
RESPONSE PDU to the MS, with Accept/Reject set to "Request rejected by the SwMI", and "Transmit 
Response Reject Cause" set to "System resources not available". The MS stops its RESPONSE_WAIT timer, 
restarts the STANDBY timer and enters STANDBY state. 

4. The MS SNDCP entity issues a SN-DELIVERY indication primitive to the service user, giving notification 
that the SN-DATA request primitive received in 1) has failed. 

28.3.5.2 Unacknowledged data service (advanced link) 

The SwMI may use also unacknowledged service (advanced link) to send N-PDUs. The procedures for 
unacknowledged data transfer differ from those of acknowledged data transfer when the destination is a group address. 
The READY timer is not activated when an MS enters READY state for reception of point to multipoint packet data. 
Also the reception of a point to multipoint N-PDU does not effect any of the SNDCP timers. 
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A scenario illustrating unacknowledged data sending from SwMI to MS using an advanced link is shown in 
figure 28.38. Each numbered step is explained in the following list. 
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Figure 28.38: Unacknowledged service, data from SwIVII to IVIS 

1 . The SwMI SNDCP receives the first SN-UNITDATA request primitive. 

2. The SwMI SNDCP sends SN-DATA TRANSMIT REQUEST PDU. The request is sent by using 
unacknowledged service (basic link) and the MAC -RESOURCE PDU contains channel allocation information 
element commanding the MS to PDCH. The STANDBY timer is stopped and the READY timer is started in 
the SwMI SNDCP (when the SN-DATA TRANSMIT REQUEST PDU is sent). The STANDBY timer is 
stopped in the MS SNDCP(when the SN-DATA TRANSMIT REQUEST PDU is received). 

3. The SwMI SNDCP receives the second SN-UNITDATA request primitive. 

4. The first N-PDU is sent to the MS by issuing SN-UNITDATA PDU. On reception of an indication from the 
MLE, in the form of an MLE-REPORTindication primitive, that the SN-UNITDATA PDU was transmitted by 
the lower layers, the SwMI SNDCP entity shall restart the READY timer. 

5. The SwMI SNDCP receives the third SN-UNITDATA request primitive. 

6. After receiving the first SN-UNITDATA PDU, the MS SNDCP passes the N-PDU to the higher layer by 
issuing SN-UNITDATA indication primitive. 

7. The second N-PDU is sent to the MS by issuing SN-UNITDATA PDU. The READY timer is re-started in the 
SwMI SNDCP. 

8. After receiving the second SN-UNITDATA PDU, the MS SNDCP passes the N-PDU to the higher layer by 
issuing SN-UNITDATA indication primitive. 

9. The third N-PDU is sent to the MS by issuing SN-UNITDATA PDU. The READY timer is re-started in the 
SwMI SNDCP. 

10. After receiving the third SN-UNITDATA PDU, the MS SNDCP passes N-PDU to the higher layer by issuing 
SN-UNITDATA indication primitive. 

11. The READY timer expires in the SwMI SNDCP and it issues SN-END OF DATA PDU, including channel 
allocation, to the MS, starts the STANDBY timer and enters STANDBY state. The MS SNDCP receives 
SN-END OF DATA PDU, starts the STANDBY timer and enters STANDBY state on the allocated channel. 
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28.3.5.2a Usage of Resource request 



If QoS was negotiated during PDP context activation, and if the current cell supports the use of QoS negotiation during 
PDP context activation, the MS SNDCP entity should normally set "enhanced jt/4-DQPSK service" information 
element to indicate "enhanced 7t/4-DQPSK service not requested" when transmitting an SN-DATA TRANSMIT 
REQUEST PDU, SN-PAGE RESPONSE or SN-RECONNECT PDU. An MS that has negotiated QoS should not 
include the conditional resource request information element unless it advised the SwMI during registration that it 
supports 7t/8-D8PSK or QAM modulation but now specifically requires a 7t/4-DQPSK PDCH. 

The MS SNDCP entity may request a 7t/4-DQPSK multislot service in PDCH access signalling. That may be indicated 
by setting the "enhanced 7t/4-DQPSK service " information element to "enhanced 7t/4-DQPSK service requested" in the 
SN-DATA TRANSMIT REQUEST (data from MS to SwMI), SN-PAGE RESPONSE (data from MS to SwMI) or 
SN-RECONNECT PDU transmitted to the peer entity. If enhanced 7t/4-DQPSK service is indicated in the PDU, the 
PDU shall also contain a conditional Resource request information element, which shall inform the SwMI of the desired 
number of slots per frame in the PDCH. The required number of jt/4-DQPSK slots per frame shall be informed to the 
SwMI before the MS has already been directed to a PDCH. In consequence this shall aid the SwMI in directing the MSs 
to the proper channels and access to resources, where the actual data transfer occurs, is immediate. 

If QoS was not negotiated during PDP context activation, and the MS requires a multislot 7t/4-DQPSK connection, and 
if the Resource request information element is not used at all, then the MS has to be directed to a single slot channel to 
do the advanced link set up, and then, after advanced link negotiation, to the actual multislot channel to do the data 
transfer. In this case the MS visits completely uselessly on a single slot channel for a short time. If the requirement for 
multislot 7t/4-DQPSK packet data is indicated earlier by using the Resource request information element, the MS can be 
moved directly to a desired multislot channel and latency time to the resource access can be reduced. 

The remainder of this clause applies only to those situations where either the MS, the SwMI, or the current cell does not 
support use of the QoS information element in the SN-ACTIVATE PDP CONTEXT REQUEST and 
SN-ACTIVATE PDP CONTEXT ACCEPT PDUs. Then the following shall apply: 

• If QoS was not negotiated during PDP context activation or the current cell does not support QoS negotiation, 
then, by default, the connection shall always be a single-slot 7t/4-DQPSK connection. If the MS requests single 
slot connection, the enhanced 7t/4-DQPSK service does not have to be indicated in PDCH access signalling. 
Then the SwMI shall send the MS to single time slot 7t/4-DQPSK PDCH and if no advanced link exists, the 
MS shall establish a single slot advanced link on the PDCH. Anyway the MS shall be on the channel where the 
actual data transfer occurs. 

• If no advanced link exists when the MS has been sent to a PDCH, and QoS was not negotiated during PDP 
context activation, the MS SNDCP entity shall use the data transfer throughput and number of 7t/4-DQPSK 
timeslots per TDMA frame parameters which were indicated in the resource request information element 
during the advanced link set up negotiation. 

• If an advanced link has already been established for the packet data service when the MS enters from 
STANDBY state to READY state (i.e. MS has visited on the PDCH at least once before), the MS shall adapt 
the requested width of the PDCH in PDCH access signalling with the already negotiated advanced link 
parameters. 

NOTE 1 : If QoS was not negotiated during PDP context activation or the current cell does not support QoS 

negotiation, the MS should always use Resource request information element in PDCH access signalling 
if more than one 7t/4-DQPSK timeslot per frame is requested to either direction on the PDCH. 

NOTE 2: This information element has only a meaning to reduce latency time to the actual multislot resource 

access preventing the visit to the single slot channel uselessly before the advanced link connection setup. 
The normal QoS negotiation between LLC peer entities may not be ignored. 

Resource request information element may be also used when dealing with single slot packet data operation. By 
indicating the requested data transfer throughput value before the MS is directed to the PDCH, the BS have a capability 
to optimize its resource allocations between several MSs on the same channel and direct them to the proper channels 
right away. Connection symmetry information element indicates whether the same number of timeslots per TDMA 
frame shall be used both on uplink and downlink. In the case of symmetric connection, the next information element. 
Number of timeslots on uplink, shall indicate the number of used slots both on uplink and downlink. In that case 
Number of timeslots on downlink information element is not needed at all. 
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Instead if asymmetric connection is indicated by the Connection symmetry information element, the information 
element Number of timeslots on downlink is also present. Then the number of used timeslots on uplink and downlink 
shall be indicated by different information elements. 

NOTE 3: The actual protocol part of asymmetric connection is outside the scope of the present document, 
i.e. different timeslot requests on uplink and downlink are not used in the present version of this 
document. 

Full capability on uplink and Full capability on downlink information elements shall indicate the MS's capability to 
handle physical resources. Any resource granting over these capability limits by the SwMI is useless, because the MS 
does not have physical capabilities to handle more timeslots in one TDMA frame than indicated by these information 
elements. 

NOTE 4: How the SwMI should handle the situation where more resources have been negotiated than indicated by 
capability limits is outside the scope of the present document. 

28.3.5.2b Unacknowledged data service (basic link) 

The unacknowledged data service (basic link) shall be used by the MS to transmit data from a PDP context for which 
real-time class data was agreed during QoS negotiation. It may also be used by the SwMI. 

When the MS SNDCP receives a SN-UNITDATA request primitive for a real-time class PDP context, it shall follow 
the normal rules for transmitting an SN-DATA TRANSMIT REQUEST PDU. When the MS receives a 
SN-DATA TRANSMIT REQUEST PDU or a SN-DATA TRANSMIT RESPONSE PDU for a real-time class PDP 
context, the MS shall follow any included channel allocation, and may then transmit any waiting SN-UNITDATA 
PDUs on the unacknowledged basic link immediately (the unacknowledged basic link does not need to be set up). 

Each SN-UNITDATA PDU shall be passed to the MLE layer in a MLE-UNITDATA request primitive, accompanied 
by an indication that the unacknowledged basic link is to be used, and an indication of the number of retransmissions of 
the SN-UNITDATA PDU and an indication of whether an FCS is required. In the case of real-time class data, the 
number of retransmissions will normally be zero. 

A scenario illustrating unacknowledged basic link data sending from MS to SwMI is shown in figure 28.39. Each 
numbered step is explained in the following list. 
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Figure 28.39: Unacknowledged basic link service, data from MS to SwMI 

1 . The MS SNDCP receives the first SN-UNITDATA request primitive. 

2. The MS SNDCP sends SN-DATA TRANSMIT REQUEST PDU. The request is sent by using acknowledged 
service (basic link). On sending the SN-DATA TRANSMIT REQUEST PDU, the MS SNDCP entity starts the 
RESPONSE_WAIT timer and enters RESPONSE-WAITING state. 

3. The MS SNDCP receives the second SN-UNITDATA request primitive. 

4. The SwMI SNDCP sends SN-DATA TRANSMIT RESPONSE PDU. The response may be sent by using the 
acknowledged basic link service of the unacknowledged basic link service and the MAC-level 

MAC -RESOURCE PDU contains a channel allocation information element commanding the MS to a PDCH. 
On transmission of the SN-DATA TRANSMIT RESPONSE PDU, the SwMI stops the STANDBY timer, 
starts the READY timer, may start a CONTEXT_READY timer (see clause 28.2.6.2) and enters state 
READY. On reception of the SN-DATA TRANSMIT RESPONSE PDU, the MS stops the STANDBY and 
RESPONSE. WAIT timers, starts the READY timer and the relevant CONTEXT_READY timer, and enters 
state READY. 

5. The MS SNDCP receives the third SN-UNITDATA request primitive. 

6. The first N-PDU is sent to the SwMI by issuing an SN-UNITDATA PDU. On reception of an indication from 
the MLE, in the form of an MLE-REPORT indication primitive, that the SN-UNITDATA PDU was 
transmitted by the lower layers, the MS SNDCP entity shall restart the READY timer and shall, if supported, 
restart the relevant CONTEXT_READY timer. At the SwMI the reception of the SN-UNITDATA PDU shall 
result in the READY timer and, if used, the CONTEXT_READY timer being restarted. 

7. After receiving the first SN-UNITDATA PDU, the SwMI SNDCP passes the N-PDU to the higher layer by 
issuing SN-UNITDATA indication primitive. 

8. The second N-PDU is sent to the SwMI by issuing SN-UNITDATA PDU. If scheduled access was agreed with 
the SwMI for this PDP context during PDP context activation, the MS SNDCP indicates that this SN-PDU is 
scheduled and indicates the value of the maximum schedule period for this PDP context in the 
MLE-UNITDATA request primitives carrying this and all subsequent SN-UNITDATA PDUs for this PDP 
context. The READY timer is re-started in the MS SNDCP and in the SwMI SNDCP. If supported, the 
relevant CONTEXT_READY timer is restarted in the MS and SwMI SNDCP. 

9. The third N-PDU is sent to the SwMI by issuing SN-UNITDATA PDU. If scheduled access was agreed with 
the SwMI for this PDP context during PDP context activation, the MS SNDCP indicates that this SN-PDU is 
scheduled. The READY timer is re-started in the MS SNDCP. If supported, the relevant CONTEXT_READY 
timer is restarted in the MS and SwMI SNDCP. 
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10. After receiving the second SN-UNITDATA PDU, the SwMI SNDCP re-starts the READY timer and, if used, 
the CONTEXT_READY timer and passes the N-PDU to the higher layer by issuing SN-UNITDATA 
indication primitive. 

1 1 . After receiving the third SN-UNITDATA PDU the SwMI SNDCP re-starts the READY timer and, if used, the 
CONTEXT_READY timer and passes the N-PDU to the higher layer by issuing SN-UNITDATA indication 
primitive. 

12. The READY timer expires in the SwMI SNDCP and it issues SN-END OF DATA PDU, including channel 
allocation, to the MS, starts the STANDBY timer and enters STANDBY state. The MS SNDCP receives 
SN-END OF DATA PDU, stops its READY timer and any CONTEXT_READY timers, starts the STANDBY 
timer and enters STANDBY state in the allocated channel. 

28.3.5.3 Protocol header compression 



28.3.5.3.1 



Header compression types 



Header compression attempts to remove redundant protocol header information of transmitted PDUs between source 
and destination addresses. The used compression method is specific for each network layer protocol type. TCP/IP 
(IPv4) and IP (IPv4 and IPv6) header compression are introduced in the present document. 

Multiple types of header compression are supported. Negotiation of supported algorithms is carried out between MS 
and SwMI in Activate PDP Context procedure, if necessary. The negotiation uses the PCOMP negotiation information 
element (8 bits bitmap) in SN-ACTIVATE PDP CONTEXT PDUs whereas the control of the compression process is 
done by using the PCOMP information element (4 bits) in SN-DATA and SN-UNITDATA PDUs. 

If the receiving SNDCP entity does not recognize the value of the PCOMP information element included in the 
SN-DATA PDU or SN-UNITDATA PDU it shall discard the PDU. 



28.3.5.3.2 



TCP/IP header compression 



RFC 1 144 [29] defines an encoding method and protocol for compressing the standard 40-octet TCP/IP (IPv4) protocol 
header down to 3 octets at minimum. The standard TCP/IP header comprises 20 octets of IP part and 20 octets of TCP 
part. The idea is to replace the IP header with a one octet connection number, and the TCP header with delta 
information (only differences are sent). 

TCP/IP header compression modes that require a reliable link should not be used with the unacknowledged layer 2 
service. 

The protocol requires that the underlying service should be able to distinguish three types of IP frames. The frame type 
information is conveyed in the PCOMP field of the SNDCP header. 

When compression is used, a TCP/IP header is replaced with a compressed header of length varying from 3 to 16 octets. 
Octet one carries a change mask that identifies which of the consequent fields has changed per packet. A mask bit is set 
if the associated field is changed and present in the header. The corresponding bit is clear if there are no changes, and 
the delta field is absent. The unmodified TCP checksum field, however, is always included in the compressed header. 
The format of the header is shown in table 28.19. 

Table 28.19: Compressed header format 



Bit 


8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 





C 


1 


P 


S 


A 


W 


u 


2 


Connection number (C) 


3 


TCP checksum 


4 






Urgent pointer (U) 




delta (Window) (W) 




delta (Ack) (A) 




delta (Sequence) (8) 


N 


delta (IP ID) (1) 
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The connection information table in each connection entity shall be initialized upon occurrence of: 

• Initial LLC connection establishment/release; or 

• At any time when the SNDCP entity concludes that the peer entity has lost TCP/IP header compression 
synchronization. 

NOTE: Where an MS moves to a new cell and establishes an advanced link, there should not be a need for the 
connection information table to be re-initialized. 

In TETRA packet data, each SNDCP entity maintains two connection state tables per PDP context, one for N-PDUs 
sent (compressor state table) and one for N-PDUs received (decompressor state table). Within each table there may be 
up to 256 state slots, thus allowing the compression of up to 256tsimultaneous TCP connections per PDP context. The 
exact number of state slots supported by SNDCP entities is negotiated at context activation. The MS shall specify in the 
SN-ACTIVATE PDP CONTEXT DEMAND PDU the number of state slots which it can support for this context. The 
SwMI shall respond in the SN-ACTIVATE PDP CONTEXT ACCEPT PDU with either the same value or a lower 
value. The lower of the values specified in the SN-ACTIVATE PDP CONTEXT DEMAND PDU and SN-ACTIVATE 
PDP CONTEXT ACCEPT PDU shall be used by both SNDCP entities. It is recommended at least 16 state slots are 
supported per PDP context. It is also recommended that implementations should avoid specifying one slot during PDP 
context activation if possible. 

28.3.5.3.3 IP header compression 

RFC 2507 [35] and RFC 2508 [36] define an encoding method and protocol for compressing multiple types of IPv4 or 
IPv6 protocol header(s). This includes UDP/IP headers, which can be compressed down to 3 octets at minimum. The 
idea is as for the TCP/IP header compression described in clause 28.3.5.3.2 to replace the IP header(s) with a one or two 
octet context number, and required delta information (only differences are sent). 

The protocol requires that the underlying service should be able to distinguish nine types of IP frames. The frame type 
information is conveyed in the PCOMP field of the SNDCP header. 

In TETRA packet data, each SNDCP entity maintains two context state tables per PDP context, one for N-PDUs sent 
(compressor context state table) and one for N-PDUs received (decompressor context state table). Within each table 
there may be up to 256 + 65 536 context state slots, thus allowing the compression of up to 256 simultaneous TCP 
connections and 65 536 simultaneous non-TCP "contexts" per PDP context. The exact number of state slots supported 
by SNDCP entities is negotiated at PDP context activation. The MS shall specify in the SN-ACTIVATE PDP 
CONTEXT DEMAND PDU the number of state slots which it can support for this context. The SwMI shall respond in 
the SN-ACTIVATE PDP CONTEXT ACCEPT PDU with either the same value or a lower value. The lower of the 
values specified in the SN-ACTIVATE PDP CONTEXT DEMAND PDU and SN-ACTIVATE PDP CONTEXT 
ACCEPT PDU shall be used by both SNDCP entities. It is recommended at least 16 state slots be supported per PDP 
context. It is also recommended that implementations should avoid specifying one slot during PDP context activation if 
possible. 

The context information table in each entity shall be initialized upon occurrence of: 

• initial LLC connection establishment/release; or 



• 



at any time when the SNDCP entity concludes that the peer entity has lost IP header compression 
synchronization. 



NOTE: Where an MS moves to a new cell and establishes an advanced link, there should not be a need for the 
context information table to be re-initialized. 

IP header compression modes that require a reliable link should not be used with the unacknowledged layer 2 service. 

28.3.5.4 Data compression 

Data compression in TETRA Packet data shall primarily be done according to the ITU-T Recommendation 
V.42bis [27]. It is also possible to use alternative compression methods, if required. 

The supported alternative data compression methods introduced in the present document are: 

• BSD Compression (RFC 1977 [32]); 
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Predictor Compression (RFC 1978 [33]). 



28.3.5.4.1 



Support of multiple compression types 



Each SNDCP entity shall be equipped with the ability to handle several compression types. Then, the means must be 
arranged between the peer SNDCP entities to negotiate and switch on the selected algorithm. 

The negotiation of the supported algorithms needs to be done prior to data transfer, and it is done between the MS and 
SwMI in Activate PDP Context procedure. The MS sends a list of algorithms that it can support. The SwMl responds 
by picking up those algorithms on the list, which it accepts, and then returns a list of the permitted algorithms back to 
the MS. The format of the negotiation information element is similar for both directions. 

Any permitted compression algorithm can be switched on during data transfer period. The selected compression type is 
identified with DCOMP parameter, which is carried in SN-DATA or SN-UNITDATA PDU frames. 

If the receiving SNDCP entity does not recognize the value of the DCOMP information element included in the 
SN-DATA PDU or SN-UNITDATA PDU it shall discard the PDU. 



28.3.5.4.2 



Management of V.42bis data compression 



According to the present document the use of data compression function and associated parameters shall be negotiated 
at initial connection establishment. The negotiated parameters, PO, PI and P2 shall be transferred between MS and 
SwMI. 
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Figure 28.40: ITU-T Recommendation V.42bis [27] data compression function 

The service interface of the ITU-T Recommendation V.42bis [27] data compression function is modelled as a set of 
abstract service primitives, figure 28.40. The control function at each end of data transfer shall issue a C-INIT request 
primitive to the data compression function after a successful negotiation of compression parameters and after 
completion of LLC link establishment. 

To encode data, the SNDCP control function shall issue a C-DATA request primitive to the data compression function, 
indicating the data to be encoded. The encoder indicates with C-TRANSFER indication primitive that the compressed 
data is ready to be delivered. 

At the receiver end the encoded data block is delivered to the decoder unit using C-TRANSFER request primitive. After 
this the decoder indicates by C-DATA indication primitive that the decoded data block is ready to be moved further. 

The C-FLUSH request primitive shall be used to preserve boundaries between network protocol data blocks (PDUs). 
The control function shall issue a C-FLUSH request primitive immediately after encoding of each PDU. 

The C-ERROR indication primitive informs the control function that an error has been detected by the decoder. The 
error situation is recovered by re-establishing the LLC connection. 
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Any subsequent PDP context activation, which requests, and is granted, ITU-T Recommendation V.42bis [27] 
compression support with different ITU-T Recommendation V.42bis [27] compression parameters, shall cause the 
ITU-T Recommendation V.42bis [27] compression dictionaries to be cleared. 



28.3.5.4.3 



Management of BSD data compression 



The BSD data compression algorithm is described in RFC 1977 [32]. RFC 1977 [32] describes the compression 
algorithm and defines the encapsulation header. The encapsulation is shown in table 28.20. 

Table 28.20: BSD compressed data format 



Bit 


8 7 6 5 4 3 2 1 


Octet 1 


Sequence 


2 


Sequence (continued) 


3 


Compressed data 


etc. 


etc. 


N 


Compressed data 



The compressed data information element is the output of the BSD algorithm when applied to the original N-PDU 
content. 

In TETRA packet data, each SNDCP entity maintains two BSD compression dictionaries, one for N-PDUs sent 
(compressor dictionary) and one for N-PDUs received (decompressor dictionary). All BSD dictionaries shall be cleared 
at context activation. 

If the decoder has detected an error, the error situation is recovered by re-establishing the LLC connection. According 
to the specification, the use of the BSD data compression function and associated parameters shall be negotiated at 
initial connection establishment. The negotiated parameters, version and dictionary size shall be transferred between 
MS and SwMI. 

Any subsequent PDP context activation, which requests, and is granted, BSD compression support with different BSD 
compression parameters shall cause the BSD compression dictionaries to be cleared. 



28.3.5.4.4 



Management of Predictor data compression 



The predictor data compression algorithm is described in RFC 1978 [33]. RFC 1978 [33] describes the compression 
algorithm and defines two types of encapsulation headers. However, only type 1 encapsulation is allowed within the 
present document. The encapsulation is shown in table 28.21. 

Table 28.21 : Predictor compressed data format 



Bit 


8 7 6 5 4 3 2 


1 


Octet 1 


Uncompressed length (octets) 


Octet 2 


Uncompressed length (continued) 


Octet 3 


Compressed data 


etc. 


etc. 


etc. 


etc. 


Octet N 


Compressed data 



The compressed data information element is the output of the predictor algorithm when applied to the original N-PDU 
content with an appended 16 bit CRC. This CRC shall be calculated as defined in RFC 1662 [31]. 

In TETRA Packet data, each SNDCP entity maintains two predictor compression dictionaries, one for N-PDUs sent 
(compressor dictionary) and one for N-PDUs received (decompressor dictionary). All predictor dictionaries shall be 
cleared at context activation. If the decoder has detected an error, the error situation is recovered by re-establishing the 
LLC connection. 

According to the specification, the use of the predictor data compression function shall be negotiated at initial 
connection establishment. There are no negotiated parameters for the predictor data compression. 
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28.3.5.5 Data Priority 

28.3.5.5.1 General 

Except where stated otherwise, this clause shall be applicable only to MSs and SwMIs which support data priority. 

SNDCP may provide support for data priority. Eight levels of data priority are available. Data priority allows an MS to 
transmit high data-priority N-PDUs ahead of lower data-priority N-PDUs from the same MS and other MSs. 

The SwMI indicates support for data priority in the "Extended services broadcast" information element of the MAC 
SYSINFO PDU. The MS SNDCP is informed of this by the broadcast parameters in the MLE-INFO indication 
primitive. 

The data priority of N-PDUs may be defined by the SNDCP service user by two different methods. The first provides a 
data priority for each PDP context and the second allows the SNDCP service user to set a data priority for individual 
N-PDUs. 

The MS has three different methods for requesting data priority from the SwMI. The first method is conducted within 
SNDCP, and is a method of requesting a change to the data priority which the SwMI applies by default to all SN-DATA 
and SN-UNITDATA PDUs transmitted by the MS. The second method is applied at layer 2 in response to information 
from the MS SNDCP, and is a method of requesting short-term variations to the default data priority. This allows the 
SwMI to respond quickly to a priority increase while minimizing the amount of signalling required to track rapidly 
changing data priorities. The third method is applied by the MLE in response to information from the MS SNDCP and 
is a method of indicating that the MS needs high priority access to a PDCH so that it can be sent to the PDCH ahead of 
other waiting MSs with lower data priority. 

N-PDUs from an MS which does not support data priority will experience the network default data priority. When an 
MS supporting data priority uses a SwMI which does not support data priority, its N-PDUs and PDCH access requests 
are given the same data priority as all other MSs' requests. 

NOTE: Data priority is distinct from PDU priority (see clause 28.6). PDU priority affects LLC queue reordering 
and the MS's permission to use random access opportunities. Data priority affects LLC queue reordering, 
slot granting delays and the speed of the MS's access to the PDCH. 

28.3.5.5.2 Network default data priority and initial MS default data priority 

Unless otherwise stated, this clause shall be applicable only to MSs and SwMIs that support data priority. 

The SwMI should set a "network default data priority". It should apply the network default data priority to reservation 
requirements from MSs that do not support data priority or have not requested a change in "MS default data priority". 
An MS may discover the value of the network default data priority in the following ways described in figure 28.41. 
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Figure 28.41 : Method by which the IVIS SNDCP discovers the networit default priority 

1 . A SwMI that supports data priority should send MSs the value of the network default data priority in the 
"data priority details" information element in the SN-ACTIVATE PDP CONTEXT ACCEPT PDU. 

2. The SwMI may inform all MSs of the network default data priority by transmitting broadcast-addressed 
SN-DATA-PRIORITY INFORMATION PDUs from time to time. If the SwMI changes the network default 
data priority it should inform all MSs of the new network default data priority by transmitting 
broadcast-addressed SN-DATA-PRIORITY INFORMATION PDUs. 



4. 



An MS SNDCP that has activated packet data context and received MLE INFO indication primitive advising 
that data priority is supported on the current cell may request the value of the network default data priority by 
sending an SN-DATA-PRIORITY REQUEST PDU to the SwMI. 

The SwMI shall then notify the MS of the value of the network default data priority in an 
SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU. 



The SwMI should set and record an initial "MS default data priority" when an MS activates a first PDP context. (This 
includes MSs which do not support data priority.) The SwMI should set the initial value of "MS default data priority" to 
the value of the "network default data priority". 

When an MS is powered-up, and when it deactivates its last PDP context, the MS SNDCP shall set its recorded value of 
"MS default data priority" to "undefined" and shall inform MLE that the MS default data priority is "not applicable" 
using the MLE-CONFIGURE request primitive. 

When the MS SNDCP receives a value of network default data priority, then: 

• if MS default data priority is "undefined", the MS SNDCP shall set MS default data priority to the value of 
network default data priority. If in the READY state and the MS wishes to use data priority, MS SNDCP shall 
then inform MLE of the MS default data priority using the MLE-CONFIGURE request primitive; or 

• if MS default data priority has been set from a previous value of network default data priority, the MS SNDCP 
shall set MS default data priority to the new value of network default data priority. If in the READY state and 
the MS wishes to use data priority, the MS SNDCP shall then inform MLE of the new MS default data priority 
using the MLE-CONFIGURE request primitive; or 
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• if MS default data priority has been set by negotiation with the SwMI, the MS SNDCP shall not set 
MS default data priority to the value of network default data priority. 

If the MS SNDCP wishes to revert a negotiated MS data priority back to the network default data priority, so that it 
tracks future values of the network default data priority, the MS SNDCP should send the SwMI 
a SN-DATA-PRIORITY REQUEST PDU with the "data priority request type" set to "set MS default data priority to 
track network default data priority". If the resulting SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU from the 
SwMI indicates that MS default data priority has been set to the network default data priority, the MS SNDCP shall set 
its local value of MS default data priority to the value of network default data priority included in the same PDU. If in 
the READY state, the MS SNDCP shall then inform MLE of the new MS default data priority using the 
MLE-CONFIGURE request primitive. 

Similarly, if the MS SNDCP receives an SN-DATA-PRIORITY INFORMATION PDU from the SwMI indicating that 
MS default data priority has been set to the network default data priority, the MS SNDCP shall set its local value of 
MS default data priority to the value of network default data priority included in the same PDU. If in the READY state, 
the MS SNDCP shall then inform MLE of the new MS default data priority using the MLE-CONFIGURE request 
primitive. 

When the MS SNDCP enters the READY state and wishes to use data priority and the MS default data priority has 
a defined value (i.e. not equal to "undefined"), it should send the value of the MS default data priority to MLE in the 
MS default data priority parameter of the MLE-CONFIGURE request primitive. When the MS SNDCP leaves the 
READY state, it shall inform MLE that the MS default data priority is "not apphcable". 

28.3.5.5.3 NSAPI data priority 

This clause shall be applicable only to MSs which support data priority. 

When an SNDCP service user requests activation of a PDP context (using the SN-NSAPI ALLOC request primitive), 

the SNDCP service user may include a default data priority for N-PDUs using that PDP context in the 

"NSAPI data priority" parameter. The MS SNDCP shall record a value for this parameter for each activated PDP 

context. It shall record the value "undefined" for any PDP context where an NSAPI data priority parameter was not 

provided. 

The SNDCP service user may ask the MS SNDCP to modify the NSAPI data priority of a particular PDP context at any 
time by use of the SN-NSAPI CONFIGURE request primitive. When the MS SNDCP receives this primitive, it shall 
replace the previously recorded value with the new value and confirm its arrival by issuing the 
SN-NSAPI CONFIGURE confirm primitive. 

If the SNDCP service user is making a long-term change to the data priority of all its N-PDUs for a particular PDP 
context, it should alter the NSAPI data priority. 

NOTE: The NSAPI data priority is intended to aid the MS in adjusting a long-term default data priority, and the 
SNDCP service user should not attempt to use the SN-NSAPI CONFIGURE request primitive to follow 
short-term changes in data priority. 

28.3.5.5.4 Changing the MS default data priority 

This clause shall be applicable only to MSs and SwMIs which support data priority. 

When the MS SNDCP needs to transmit an SN-DATA TRANSMIT REQUEST PDU, when the SNDCP service user 
requests a change in an NSAPI data priority, or when a CONTEXT_READY timer expires or is stopped, the MS 
SNDCP should compute a preferred default data priority. 

The MS SNDCP should compute the preferred default data priority by examination of the recorded 

"NSAPI data priority" for each PDP context that is actively sending or receiving data (i.e. for each PDP context with an 

active CONTEXT_READY timer, or, if CONTEXT_READ Y timers are not supported, for the PDP context that is 

presently keeping the READY timer active). The MS SNDCP may include in its computation the 

"mean active throughput" values of those PDP contexts which are actively attempting to transmit N-PDUs. The MS's 

preferred default data priority should be an estimate of the modal value of the data priority of the SN-DATA or 

SN-UNITDATA PDUs that the MS currently expects to transmit. 
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If the MS's preferred default data priority is different from the current "MS defauh data priority", the MS SNDCP may 
request a change to MS defauh data priority by sending an SN-DATA-PRIORITY REQUEST PDU to the SwMI (it 
should first transmit any pending SN-DATA TRANSMIT REQUEST PDU). The SwMI shall respond to the 
SN-DATA-PRIORITY REQUEST PDU with an SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU accepting or 
rejecting the request, refer to figure 28.42. The MS SNDCP shall not change its value of MS default data priority if the 
request is rejected. If the request is accepted, the MS SNDCP shall set its value of MS default data priority to the value 
included with the SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU. (The SwMI need not set this to the value 
requested by the MS). If the request is accepted and SNDCP is in the READY state, the MS SNDCP shall inform MLE 
of the new value of MS default data priority using the MLE-CONFIGURE request primitive. 



MS 



SwMI 



SNDCP 



SNDCP 



Preferred data priority is 
not tlie same as MS 
default data priority 



1. SN-Data Priority Request 



2. SN-Data Priority Acknowledgement 



(network default data priority, MS default data priority) 
Figure 28.42: SNDCP changes MS default priority 

The MS shall not transmit an SN-DATA-PRIORITY REQUEST PDU containing the same information as 
a previously-transmitted SN-DATA-PRIORITY REQUEST PDU or requesting the same or lower 
MS default data priority than a previously-transmitted SN-DATA-PRIORITY REQUEST PDU until time 
DATA_PRIORITY_REQUEST_WAIT has elapsed since the previous transmission of the 
SN-DATA-PRIORITY REQUEST PDU. 

The SwMI may decide to change the MS default data priority for its own reasons. If it changes the 

MS default data priority it should inform the MS concerned using an individually-addressed 

SN-DATA-PRIORITY INFORMATION PDU. If the MS default data priority is changed and SNDCP is in the READY 

state and has informed MLE that the MS default data priority has a value other than "not applicable", the MS SNDCP 

shall inform MLE using the "MS default data priority" parameter in the MLE-CONFIGURE request primitive. 

28.3.5.5.5 Short-term data priorities 

This clause shall be applicable only to MSs which support data priority. 

SN-DATA and SN-UNITDATA request primitives from the SNDCP service users may include a data priority 
parameter. 

When the MS SNDCP sends an SN-DATA PDU or SN-UNITDATA PDU to the MLE in an MLE-UNITDATA request 
primitive, the MS SNDCP shall include a data priority parameter in the MLE-UNITDATA request primitive. This data 
priority parameter shall be set as follows: 

• if the SN-DATA PDU or SN-UNITDATA PDU is scheduled (see clause 28.3.5.6) then the data priority 
parameter shall be set to "undefined" (this includes data which is surplus to the schedule); 

• if the SN-DATA PDU or SN-UNITDATA PDU is "initial scheduled data" (see clause 28.3.5.6) then the data 
priority parameter may be set to "undefined" or may be set using the following methods for data which is not 
scheduled; 
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• if the SN-DATA PDU or SN-UNITDATA PDU is not scheduled and there was no data priority parameter in 
the matching SN-SAP primitive, then: 

if the "NSAPI data priority" is "undefined" and the MS default data priority is "undefined" then the data 
priority parameter in the MLE-UNITDATA request primitive shall not take the value "undefined" but 
should be set to the value "2"; 

if the "NSAPI data priority" is "undefined" and the MS default data priority is not "undefined" then the 
data priority parameter in the MLE-UNITDATA request primitive shall take the value of the MS default 
data priority; 

if the "NSAPI data priority" is not "undefined" then the data priority parameter in the 
MLE-UNITDATA request primitive shall take its value from the "NSAPI data priority"; 

• if the SN-DATA PDU or SN-UNITDATA PDU is not scheduled and there was a data priority parameter in the 
matching SN-SAP primitive then the data priority parameter in the MLE-UNITDATA request primitive shall 
take its value from the data priority parameter in the matching SN-SAP primitive. 

When sending an SN-DATA or SN-UNITDATA PDU, the MS SNDCP shall set the packet data flag in the 
MLE-UNITDATA request primitive to indicate that the PDU contains packet data. (For all other PDUs, the 
MS SNDCP shall set the flag to indicate that the PDU does not contain packet data.) 

28.3.5.5.6 Short term data priority control 

This clause shall be applicable only to MSs which support data priority. 

The "Layer 2 data priority lifetime" and "Layer 2 data priority signalling delay" timer values and the "Data priority 
random access delay factor" are used by layer 2 for control of the short term data priority. 

Whenever these items are received by the MS SNDCP in the "data priority details" information element of a 
SN-ACTIVATE PDP CONTEXT ACCEPT, SN-DATA-PRIORITY INFORMATION or SN-DATA-PRIORITY 
ACKNOWLEDGEMENT PDU, the MS SNDCP shall inform MLE of their values using the MLE-CONFIGURE 
request primitive. 

The SwMI should transmit broadcast-addressed SN-DATA-PRIORITY INFORMATION PDUs if it wishes to change 
or update MSs' recorded values of any of the items in the "data priority details" information element. 

28.3.5.5.7 Data priority of SN-DATA TRANSMIT REQUEST and SN-RECONNECT PDUs 

This clause shall be applicable only to MSs which support data priority. 

If the current cell supports data priority, the MS SNDCP may ask the MLE to include data priority with an 
SN-DATA TRANSMIT REQUEST PDU or SN-RECONNECT PDU by setting the MLE data priority flag parameter to 
"MLE data priority signalling required" in the MLE-UNITDATA request primitive carrying the SNDCP PDU, and 
including a data priority parameter with a defined value (i.e. shall not be set to "undefined"). The data priority parameter 
should be set to the highest data priority of those SN-DATA PDUs which are waiting to be transmitted using the NSAPI 
included in the SN-DATA TRANSMIT REQUEST or SN-RECONNECT PDU. 

NOTE: This causes the MS MLE to inform the SwMI that the PDCH request implicit in the SNDCP PDU should 
be given an appropriate data priority by the SwMI, with the objective of reducing the MS's waiting time 
for access to the PDCH. 

The MLE data priority flag shall be set to "MLE data priority signalling not required" for all PDUs other than 
SN-DATA TRANSMIT REQUEST and SN-RECONNECT, and for all PDUs when the current cell does not support 
data priority. 

28.3.5.6 Scheduled Access 

SNDCP provides a scheduled data service known as scheduled access. Scheduled access is available on the uplink for 
the acknowledged data service and the unacknowledged data service (basic link). It is intended for use by real-time 
class data and telemetry class data generated by an MS SNDCP service user at regular intervals. Use of a schedule 
reduces the need for the MS to make random access requests to send its scheduled data, and therefore increases channel 
efficiency. Scheduled access is available only when SNDCP supports QoS negotiation during PDP context activation. 
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If an MS SNDCP service user specifies a schedule in an SN-NS API ALLOC request primitive, if the MS and SwMI 
support QoS negotiation during PDF context activation and if the MS supports scheduled access, the MS SNDCP shall 
request a schedule in the QoS information element of the SN- ACTIVATE PDP CONTEXT DEMAND PDU. 

When requesting a schedule, the MS SNDCP shall convert the N-PDU sizes specified by the MS SNDCP service user 
into SN-DATA or SN-UNITDATA PDU sizes, taking into account the SNDCP header and the effects of IP header 
compression and data compression, and, in the case of real-time class data, the number of transmission repetitions it 
requires for each SN-UNITDATA PDU. 

If the schedule is agreed by the SwMI, when the SwMI receives a SN-DATA or SN-UNITDATA PDU from the MS for 
that PDP context, the SwMI shall commence or continue sending regular slot grants to the MS with the repetition period 
and timing accuracy agreed during the PDP context negotiation. 

When the MS SNDCP sends an SN-DATA or SN-UNITDATA PDU to MLE from a PDP context with a schedule for 
the first time after activation of that PDP context, it shall inform MLE that it requires schedule timing prompts to be 
started for the relevant NSAPI (using the schedule repetition information parameter in an MLE-CONFIGURE request 
primitive). 

The MS SNDCP may inform MLE that the schedule timing prompts for a particular PDP context can be stopped (using 
the schedule repetition information parameter in the MLE-CONFIGURE request primitive) when the PDP context 
containing the schedule is deactivated or when SNDCP returns to the STANDBY state or if the MS SNDCP is informed 
that the SwMI has suspended or cancelled the schedule. 

If MS SNDCP decides to resume use of a schedule after it has informed MLE that the schedule timing prompts may be 
stopped, it shall inform MLE that it requires schedule timing prompts to be started for the relevant NSAPI when it sends 
to MLE the next SN-DATA or SN-UNITDATA PDU for that PDP context. 

If a schedule has been agreed for a PDP context, the MLE-UNITDATA request primitive carrying the first SN-DATA 
or SN-UNITDATA PDU from that PDP context following activation of the PDP context shall indicate in the 
"scheduled data status" parameter that the SN-DATA or SN-UNITDATA PDU is "initial scheduled data". The 
"scheduled data status" of subsequent SN-DATA or SN-UNITDATA PDUs for that PDP context shall be set to 
"scheduled data" and the MLE-UNITDATA request primtives shall include the "maximum schedule interval" for the 
PDP context. (The maximum schedule interval is sum of the schedule repetition period and the schedule timing error.) 

If there is a substantial gap in the arrival of N-PDUs from the SNDCP service user, such that the MS SNDCP has no 
data to transmit for a particular schedule for several schedule periods (for example, when SNDCP returns to the 
STANDBY state) the MS SNDCP may indicate to the MLE that the first SN-DATA or SN-UNITDATA PDU after the 
gap is "initial scheduled data". The subsequent SN-DATA or SN-UNITDATA PDUs shall be marked as "scheduled 
data". 

NOTE 1: The indication that an SN-DATA or SN-UNITDATA PDU is "initial scheduled data" allows layer 2 to 
speed up the re-establishment of a schedule in the event that the SwMI has paused the scheduled slot 
grants during a gap in the MS's use of the scheduled slot grants. 

"Initial scheduled data" SN-DATA and SN-UNITDATA PDUs may be sent to the MLE immediately. "Scheduled data" 
SN-DATA and SN-UNITDATA PDUs shall be buffered by the MS SNDCP until receipt of an MLE-INFO indication 
request primitive containing a "schedule timing prompt" parameter for the relevant NSAPI. 

SN-DATA request and SN-UNITDATA request primitives containing an N-PDU for a PDP context with a schedule 
may be labelled "not surplus to schedule" or "surplus to schedule" by the SNDCP service user. N-PDUs which are 
surplus to schedule are N-PDUs in excess of the number of N-PDUs per schedule interval which the MS ageed with the 
SwMI during the PDP context activation. The MS SNDCP limits transmission of "not surplus to schedule" N-PDUs to 
the agreed number of N-PDUs per schedule period. If the application delivers these N-PDUs irregularly (e.g. more than 
one schedule period early), the MS SNDCP buffers them and delivers them at the agreed schedule intervals and 
numbers. The MS SNDCP does not limit the number of N-PDUs labeled "surplus to schedule", apart from delaying 
them until arrival of the next schedule timing signal from MLE. 

When the relevant schedule timing prompt is received, the MS SNDCP shall start sending its buffered N-PDUs to the 
MLE in order of receipt. It shall count the number of those N-PDUs that arrive for this PDP context since the last 
scheduled transmission having no label or having the label "not surplus to schedule", and shall stop sending buffered 
N-PDUs for this PDP context if transmission of the next N-PDU would cause the count to exceed the agreed number of 
N-PDUs per schedule for this schedule. 

New N-PDUs arriving after this time shall be buffered until arrival of the next schedule timing prompt. 
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NOTE 2: This permits the MS SNDCP to transmit "surplus to schedule" N-PDUs on the current schedule timing 
prompt without delaying following N-PDUs scheduled to be sent on the next schedule timing prompt. 

If SNDCP re-negotiates the period of a schedule, the MS SNDCP shall inform MLE that it requires the schedule timing 
prompts for the relevant NSAPI to be re-started by issuing the new schedule repetition information in an 
MLE-CONFIGURE request primitive. 

The data priority of a "scheduled data" SN-DATA or SN-UNITDATA PDU shall be set to "undefined". 
"Initial scheduled data" SN-DATA or SN-UNITDATA PDUs may be given a data priority. 

If the lower layers fail to provide an MLE-REPORT indication primitive indicating transmission or failure of an 
SN-UNITDATA PDU containing a scheduled real-time class N-PDU by the time the MS is due to send the next N-PDU 
in the schedule, the MS SNDCP may attempt to cancel the previous unsent SN-UNITDATA PDU for that PDP context 
by issuing an MLE-CANCEL request primitive. 

If SNDCP decides to cancel N-PDUs, it should preferentially cancel N-PDUs with low "data importance" (as indicated 
in the SN-DATA or SN-UNITDATA request primitives). 

When an MS SNDCP service user stops using a PDP context temporarily it may notify the MS SNDCP in a SN-NSAPI 
MODIFY request primitive advising that it is pausing use of the schedule or of the entire PDP context. In either case, if 
the current cell supports QoS negotiation during PDP context activation, the MS SNDCP shall notify the SwMI SNDCP 
by sending an SN-MODIFY PDP CONTEXT USAGE PDU to the SwMI. 

The SwMI may pause a schedule if the MS SNDCP notifies it that it is pausing use of the schedule or PDP context. 

The SwMI may also pause a schedule if the MS stops using the scheduled resource for a sufficient period of time (the 
time is not specified in this document). 

The SwMI pauses a schedule by ceasing to provide scheduled slot grants for that PDP context. The SwMI shall resume 
provision of slot grants for a paused schedule when it next receives an SN-DATA or SN-UNITDATA PDU for that 
PDP context. 

The SwMI may suspend a schedule for a particular PDP context: 

• if the SwMI needs to grant resource to an MS wishing to transmit N-PDUs with data priority 7; or 

• if the SwMI can no longer provide sufficient resource to support the agreed schedule. 

On a cell supporting QoS negotiation during PDP context activation, the SwMI shall suspend a schedule by sending an 
SN-MODIFY PDP CONTEXT AVAILABILTY PDU to the MS with the "PDP context availability" information 
element set to "schedule suspended". When the MS SNDCP receives this message, it shall notify the SNDCP service 
user that the schedule is suspended by issuing an SN-NSAPI MODIFY indication primitive. The MS SNDCP may 
attempt to renegotiate the schedule when this occurs. SNDCP may delete or cancel N-PDUs received for this 
PDP context from the SNDCP service user while the schedule is suspended (in which case it shall inform the SNDCP 
service user by issuing SN-DELIVERY indication primitives). 

When the SwMI is able to support a suspended schedule again and the PDP context is still activated, the SwMI shall 
inform the MS by sending an SN-MODIFY PDP CONTEXT AVAILABILITY PDU with the "PDP context 
availability" information element set to "PDP context available for use". When the MS SNDCP receives this message it 
shall notify the SNDCP service user that the PDP context is available by issuing the SN-NSAPI MODIFY indication 
primitive. 

When an MS with an agreed schedule reselects a cell which does not support QoS negotiation during PDP context 
activation, the MS shall regard the schedule as suspended, shall stop the relevant CONTEXT-READY timer, and shall 
notify the SNDCP service user that the PDP context is suspended by issuing an SN-NSAPI MODIFY indication 
primitive. SNDCP may delete or cancel N-PDUs received from the SNDCP service user for this PDP context while the 
schedule is suspended, in which case it shall inform the SNDCP service user by issuing SN-DELIVERY indication 
primitives. When the MS returns to a cell supporting QoS negotiation during PDP context activation, the MS should 
regard the schedule as available and may notify the SNDCP service user that the PDP context is available by issuing the 
SN-NSAPI MODIFY indication primitive. 

The SwMI may cancel a schedule if it wishes to permanently reallocate the scheduled resource. 
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The SwMI shall cancel a schedule by sending the MS a SN-MODIFY PDP CONTEXT REQUEST PDU whose QoS 
information element does not include the schedule. The MS SNDCP service user shall reply to this with a 
SN-MODIFY PDP CONTEXT RESPONSE PDU confirming the modified QoS, and shall notify the SNDCP service 
user that the schedule has been cancelled by issuing a SN-NSAPI MODIFY indication primitive. After the schedule has 
been cancelled, the MS SNDCP may cancel or delete N-PDUs queued or received for this PDP context from the 
SNDCP service user (in which case it shall inform the SNDCP service user by issuing SN-DELIVERY indication 
primitives). On a cell not supporting PDP context modification, the SwMI cannot cancel the schedule but may choose to 
deactivate the PDP context. 

28.3.6 Packet data paging mechanism 

A paging mechanism has been defined within SNDCP to provide the following three functions: 

• to allow a SwMI to determine the current location of a MS which is in state STANDBY (or state 
RESPONSE- WAITING), in order to deliver data; 



• 



to provide a method for the SwMI to discover which channels the MS can use in advance of delivering data to 
the MS (the MS-MLE adds advice about usable channels to the paging response from the MS SNDCP); 



• to provide a mechanism by which a SwMI may indicate that there is outbound data awaiting delivery to this 
MS and allow the MS to indicate whether it is available to accept this data. 

There are three main scenarios where the paging mechanism may be used. Firstly where data arrives in the SwMI for a 
MS which is in STANDBY (or RESPONSE-WAITING) state, and if the SwMI is unsure of the exact location of the 
MS (e.g. due to there being multiple cells per registration area), then the SwMI may page the MS. Secondly where data 
arrives in the SwMI for a MS which is presently in STANDBY (or RESPONSE-WAITING) state and the SwMI wishes 
to discover which (if any) non-conforming channels the MS is presently able to use for receiving the data, then the 
SwMI may page the MS. Thirdly where data arrives in the SwMI for a MS which is in STANDBY state, and the SwMI 
wishes to first check to see if the MS is available for packet data service, then the SwMI may page the MS. This third 
scenario may be useful when considering service interaction with Type B,C and D of MS. This paging mechanism 
allows a MS to decide whether it wishes to drop its current service in order to switch to the packet data service. 

Upon reception of a page request from the SwMI, the MS SNDCP entity may act in one of the following ways: 

1) Where the SwMI indicates that no SNDCP response is requested, then the MS SNDCP entity shall take no 
further action. In this case the page request shall be carried using the basic link acknowledged service. 

NOTE 1 : As the page request is carried using the basic link acknowledged service, hence by acknowledging this 
basic link message, the MS is implicitly responding to the page. 

2) Where the SwMI indicates that a SNDCP response is requested, the MS SNDCP entity may respond indicating 
whether it is available or temporarily unavailable for packet data service. The MS may set the "Stealing 
Permission" parameter in the MLE-UNITDATA request primitive used to pass the SN-PAGE RESPONSE 
PDU to the MLE, to "steal immediately". 

3) Where the MS does not have an active PDP context, the MS SNDCP entity may respond by the 
SN-DEACTIVATE PDP CONTEXT DEMAND PDU initiating the MS originated PDP context deactivation 
procedure (see clause 28.3.3.6.1). 

NOTE 2: The MS may respond with the "Deactivation type" set to "Deactivate all NS APIs" if no active PDP 

context exist. If PDP contexts do exist at the MS, the MS may respond with the "Deactivation type" set to 
"Deactivate NSAPI given in the PDU" if the NSAPI identified in the SN-PAGE REQUEST PDU is not 
recognized by the MS. 
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Figure 28.43 shows the scenario where the MS SNDCP entity responds to a page received from the SwMI. 
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Figure 28.43: SwMI Pages MS, MS SNDCP entity responds 

28.3.7 TETRA IP user authentication 

Figure 28.44 illustrates the reference model of IP user authentication when using PPP and RADIUS protocols, refer to 
RFC 1661 [30] and RFC 2865 [37]. In the model an AAA server and the RADIUS protocol are used to verify the user 
access. Other alternatives for the model are also possible. For instance inside the SwMI there could be a user 
authentication entity to provide the same functionality as the external AAA server. 
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Figure 28.44: IP user authentication model 

Following assumptions are made: 

• PPP is the link layer protocol used between a TETRA Terminal Equipment (TE) and a TETRA Mobile 
Termination (MT); 

• there is a requirement to authenticate the TE using PAP or CHAP, refer to RFC 1994 [34]; 

• the TE is the peer that shall be authenticated, and the MT is the authenticator, using the terminology defined in 
ISO/IEC 8348 [i.7]; 

• there is a requirement to support the PPP authentication with a centralized AAA server which is accessed by 
RADIUS protocol as defined in RFC 2865 [37]; 

• the PAP or CHAP authentication information collected in the MT is forwarded over the TETRA Air Interface 
to the TETRA SwMI; 

• inside the TETRA SwMI is a RADIUS client entity which forwards the authentication information to the 
external AAA server. 

Figure 28.45 illustrates the phases of a packet data context setup upon a successful authentication with CHAP. 
Corresponding signalling using PAP authentication would be slightly more straightforward. 
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Figure 28.45: A successful authentication with CIHAP 

Following steps clarifies the figure above: 

1. PPP/LCP negotiates the Maximum-Receive-Unit and authentication options; 

2. When using CHAP (or PAP), the TE authenticates itself to the MT, which stores the information (username, 
challenge and response, or password when using PAP) and sends an accept to TE; 

3. TE requests IP configuration from the MT using PPP/IPCP, either defining a static address, or requesting an 
address from the network; 

4. MT sends an ACTIVATE PDP CONTEXT DEMAND PDU to SwMI, containing in the Protocol 
configuration option information element the authentication and configuration information it has collected; 

5. RADIUS client in SwMI sends an Access-Request to AAA Server using RADIUS protocol; 

6. AAA Server sends an Access-Accept to RADIUS Chent; 

7. SwMI sends an ACTIVATE PDP CONTEXT ACCEPT PDU to MT; 

8. MT sends an IPCP Configure Ack to TE and the link is open (or dropped if negotiation failed). 

28.3.8 TETRA Packet data over the air provisioning 

As indicated in figure 28.44, the TETRA reference model in many ways resembles the reference model used by many 
IP service providers. Here, the PPP establishment mechanisms are used as a flexible, easily expandable way to 
provision essential information to the dial up client at connection establishment. Similar information is required at the 
TE/MT in the TETRA environment, and the TETRA standard therefore allows for such parameters to be provisioned to 
the TE/MT at context activation. 
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This information should be transferred to the TE/MT contained in an IPCP Configuration- Ack within the Protocol 
configuration options information element in the SN-ACTIVATE PDP CONTEXT ACCEPT PDU. The SwMI may 
include IPCP configuration options specifying (but not limited to): 

• Primary and secondary DNS servers; 

• Primary and secondary NBNS servers. 

The MT shall be prepared to receive Protocol configuration options information elements with Protocol identity set to 
IPCP (8021H). The MT may ignore the IPCP protocol or IPCP configuration options. 

NOTE: Ignoring received information is dissimilar to normal PPP behaviour but required here as the MT can not 
reject received information. 

28.3.9 QoS filters 

The MS shall not include a QoS filter specification in the QoS information element when requesting activation of a 
primary PDP context. 

When the MS requests activation of a secondary PDP context it may include a QoS filter specification in the QoS 
information element. If the SwMI does not support the proposed QoS filter, either the SwMI shall accept the activation 
request and propose an alternative QoS filter specification or the SwMI shall reject the activation request (e.g. with 
reject cause "QoS filter type not supported" or "Specified QoS filter not supported"). 

If the MS does not include a QoS filter specification in the activation request for a secondary PDP context, either the 
SwMI shall accept the activation request and shall generate an automatic QoS filter for that PDP context (see 
clause 28.1), or the SwMI shall reject the activation request with reject cause "Automatic QoS filter not supported". 

After a secondary PDP context has been activated, the MS may ask the SwMI to modify the QoS filter by sending the 
SwMI an SN-MODIFY PDP CONTEXT REQUEST PDU. The MS may ask the SwMI to: 

• add additional items to the existing the QoS filter; 

• remove items from the existing QoS filter; or 

• replace the existing QoS filter with a different QoS filter. 

Depending on the value of the QoS filter operation information element in the QoS filter information element, the 
SwMI shall add the QoS filter in the SN-MODIFY PDP CONTEXT REQUEST PDU to the existing QoS filter, or 
replace any existing QoS filter for the specified PDP context with the new QoS filter, or remove the QoS filter from the 
specified PDP context. An MS should not attempt removal of a QoS filter that it has not previously established. 

If the SwMI is using an automatic QoS filter for a particular PDP context when it receives a request from the MS to 
replace the QoS filter for that same PDP context, the SwMI shall stop using that automatic QoS filter. If the SwMI is 
using an automatic QoS filter for a particular PDP context when it receives a request from the MS to add a QoS filter to 
that same PDP context, the SwMI shall, if it accepts the request, combine the newly requested QoS filter with the 
automatic QoS filter and use the new combined QoS filter with that PDP context until the MS replaces the existing QoS 
filter for that PDP context with a new QoS filter. 

Where a downlink data packet matches more than one automatic QoS filter, the SwMI shall use the PDP context whose 
automatic QoS filter was most recently updated with the matching item. 

Where a downlink data packet matches more than one explicitly-defined QoS filter, the SwMI shall use the PDP context 
whose explicitly-defined QoS filter was most recently updated with the matching item. 

Where a downlink data packet matches an automatic QoS filter and an explicitly-defined QoS filter, the SwMI shall use 
the PDP context with the explicitly-defined QoS filter. 
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EXAMPLE: A SwMI has automatic QoS filters for NSAPIs 2 and 3 that presently accept data packets for 

downlink destination ports 1005 and 1006 respectively. The SwMI also has an explicitly defined 
QoS filter for NSAPI 4 that accepts data packets for downlink destination port 1007. The SwMI 
now receives some uplink packets via NSAPI 3 from source ports 1005 and 1007, so the SwMI 
updates NSAPI 3's QoS filter to accept packets for downlink destination ports 1005, 1006 and 
1007. Shortly afterwards, the SwMI receives a downlink packet for destination port 1007. The 
SwMI sends this packet to the MS via NSAPI 4 because NSAPI 4's explicitly-defined QoS filter 
takes precedence over the automatic QoS filter of NSAPI 3. Then the SwMI receives a downlink 
packet for destination port 1005. The SwMI sends this packet to the MS via NSAPI 3 because port 
1005 was added to NSAPI 3 more recently than to NSAPI 2. When the filter on NSAPI 3 is 
subsequently removed, the SwMI sends packets for downlink destination port 1005 via NSAPI 2. 

If the MS includes a QoS filter specification in a secondary PDP context activation or modification request and the 
SwMI accepts the activation or modification request but includes no QoS filter specification in its response, the MS 
shall assume that the requested QoS filter has been applied by the SwMI. 

If the MS does not include a QoS filter specification in a secondary PDP context activation request and the SwMI 
accepts the activation request but includes no QoS filter specification in its response, the MS shall assume that an 
automatic QoS filter has been applied by the SwMI. 

If the MS includes a QoS filter specification in a PDP context activation or modification request and the SwMI accepts 
the activation or modification request, but includes in its response a QoS filter specification which differs from the QoS 
filter requestd by the MS, the MS shall assume that the QoS filter specified by the SwMI has been applied. 

28.4 SN-PDU formats 

The general format of the PDU encoding is as defined in annex E of the present document. 

The information elements shall be transmitted in the order specified by the table with the top information element being 
transmitted first. The content of an information element is represented by a binary value and the most significant bit of 
that binary value shall be transmitted first. 

The information contained in the PDU description tables which follow corresponds to the following key: 

• Length: length of the information element in bits; 

• Type: information element type (1, 2 or 3) as defined in annex E; 

• C/O/M: conditional/optional/mandatory information in the PDU; 

• Remark: comment. 
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28.4.1 PDU priority 

At the transmitting end the message PDU priority management at SNDCP level is done before any other operations. 
Each PDU priority has its own queue that is mapped to the corresponding queue in LLC (MLE passes messages without 
changing their order). By doing so, for instance, a long file transfer PDU can be quickly bypassed by any other message 
that has a higher PDU priority. Eight PDU priority levels are used, number 7 representing the highest PDU priority. The 
PDU priorities for SN-PDUs shall be set according to table 28.22. 

Table 28.22: PDU priority for SN-PDUs 



SN-PDU 


PDU priority 


SN-ACTIVATE PDP CONTEXT DEMAND 


4 


SN-DEACTIVATE PDP CONTEXT DEMAND 


4 


SN-ACTIVATE PDP CONTEXT ACCEPT 


4 


SN-ACTIVATE PDP CONTEXT REJECT 


4 


SN-DEACTIVATE PDP CONTEXT ACCEPT 


4 


SN-DATA-PRIORITY REQUEST 


4 


SN-DATA-PRIORITY ACKNOWLEDGEMENT 


4 


SN-DATA-PRIORITY INFORMATION 


4 


SN-MODIFY PDP CONTEXT DEMAND 


4 


SN-MODIFY PDP CONTEXT RESPONSE 


4 


SN-MODIFY PDP CONTEXT AVAILABILITY 


4 


SN-MODIFY PDP CONTEXT USAGE 


4 


SN-UNITDATA 


see note 


SN-DATA 


see note 


SN-DATA TRANSMIT REOUEST 


see note 


SN-DATA TRANSMIT RESPONSE 


see note 


SN-RECONNECT 


4 


SN-PAGE REOUEST 


4 


SN-PAGE RESPONSE 


4 


SN-END OF DATA 


4 


SN-NOT SUPPORTED 


4 


NOTE: The maximum value for PDU priority is defined in SN-ACTIVATE PDP CONTEXT ACCEPT PDU 
"PDU priority max" information element for each NSAPI. The value used in the MLE-UNITDATA 
request primitive is given in the SN-DATA/UNITDATA request primitive. If the value given by the 
higher layer is higher than the "PDU priority max" information element indicates, then the PDU 
priority is decreased by the SNDCP to the value indicated in the "PDU priority max" information 
element. If the value is not given in the SN-DATA/UNITDATA request primitive, then the SNDCP 
uses value indicated in the "PDU priority max" information element. 



At the receiver end there is no need for queuing mechanism. 

28.4.2 Maximum N-PDU size 

The maximum N-PDU size is assigned by the SwMI at context activation using the parameter "Maximum transmission 
unit". This value represents the maximum N-PDU size which is allowed. This size refers to the maximum size of a 
N-PDU prior to the addition of the SNDCP header and the application of any compression. 

The Maximum transmission unit should always be less than the Maximum size of a TL-SDU, which is negotiated 
during advanced link setup. Hence where the SwMI sets Maximum transmission unit to 1 500 octets at context 
activation, then the negotiated maximum size of TL-SDU at advanced link setup should be 2 048 octets. 

28.4.3 PDU not supported 

In case the receiving MS or SwMI SNDCP entity receives an unknown SN PDU, the receiving entity should sent the 
SN-NOT SUPPORTED PDU. The behaviour of the requesting party when receiving SN NOT SUPPORTED PDU is 
outside the scope of the present document. The meaning of this functionality is only to maintain backward compatibility 
of the systems. 
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28.4.4 SN PDU description tables 



28.4.4.1 SN-ACTIVATE PDP CONTEXT ACCEPT 

SN- ACTIVATE PDP CONTEXT ACCEPT PDU shall contain information elements as defined in table 28.23. 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



SN-ACTIVATE PDP CONTEXT ACCEPT PDU 



SN-ACTIVATE PDP CONTEXT DEMAND PDU 



Table 28.23: SN-ACTIVATE PDP CONTEXT ACCEPT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-ACTIVATE PDP 
CONTEXT ACCEPT 


NSAPI 


4 




M 




PDU priority max 


3 




M 




READY timer 


4 




M 




STANDBY timer 


4 




M 




RESPONSE WAIT timer 


4 




M 




Type identifier in accept 


3 




M 




IP Address IPv4 


32 




C 


see note 1 


PCOIVIP negotiation 


8 


1 


M 




Number of Van Jacobson compression state slots 


8 




C 


see note 2 


Number of compression state slots, TCP 


8 




C 


see note 3 


Number of compression state slots, non-TCP 


16 




c 


see note 3 


Maximum interval between full headers 


8 




c 


see note 3 


Maximum time interval between full headers 


8 




c 


see note 3 


Largest header size in octets that may be compressed 


8 




c 


see note 3 


Maximum transmission unit 


3 


1 


M 




SNDCP network endpoint identifier 


16 


2 





see note 4 


SwMI IPv6 information 


98 


2 







SwMI Mobile IPv4 information 


71 


2 







DCOMP negotiation 


varies 


3 





see note 5 


Protocol configuration options 


varies 


3 





see note 6 


Data priority details 


24 


3 







QoS 


varies 


3 







NOTE 1 : Shall be conditional on the value of Type Identifier in Accept (TIA): 

- when TIA = 1 or 2 the information element shall be present; 

- for all other values of TIA the information element shall not be present. 
NOTE 2: Shall be conditional on the value of bit 1 (LSB) of PCOMP negotiation: 

- when bit 1 of PCOMP negotiation = the information element shall not be present; 

- when bit 1 of PCOMP negotiation = 1 the information element shall be present. 
NOTE 3: Shall be conditional on the value of second LSB of PCOMP negotiation: 

- when bit 2 of PCOMP negotiation = the information element shall not be present; 

- when bit 2 of PCOMP negotiation = 1 the information element shall be present. 
NOTE 4: For usage, refer to clause 28.3.3.3. 

NOTE 5: There may be more than one DCOMP negotiation information element if more than one compression 

mechanism is assigned for a single NSAPI. 
NOTE 6: The maximum length shall be 128 octets. 
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28.4.4.2 SN-ACTIVATE PDP CONTEXT DEMAND 

SN- ACTIVATE PDP CONTEXT DEMAND PDU shall contain information elements as defined in table 28.24. 



Message: 
Response to: 
Response expected: 

Short description: 



SN-ACTIVATE PDP CONTEXT DEMAND PDU 

SN-ACTIVATE PDP CONTEXT ACCEPT PDU 
/SN-ACTIVATE PDP CONTEXT REJECT PDU 



Table 28.24: SN-ACTIVATE PDP CONTEXT DEMAND PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-ACTIVATE PDP 
CONTEXT DEMAND 


SNDCP version 


4 


1 


M 




NSAPI 


4 


1 


M 


see notes 1 and 2 


Address type identifier in demand 


3 


1 


M 


see note 3 


IP Address IPv4 


32 




C 


see note 4 


NSAPI 


4 




C 


see notes 5 and 6 


Pacl<et data IVIS Type 


4 


1 


M 




PCOIVIP negotiation 


8 


1 


M 




Number of Van Jacobson compression state slots 


8 




C 


see note 7 


Number of compression state slots, TCP 


8 




C 


see note 8 


Number of compression state slots, non-TCP 


16 




c 


see note 8 


Maximum interval between full headers 


8 




c 


see note 8 


Maximum time interval between full headers 


8 




c 


see note 8 


Largest header size in octets that may be compressed 


8 




c 


see note 8 


Access point name index 


16 


2 





see note 9 


DCOMP negotiation 


varies 


3 







Protocol configuration options 


varies 


3 





see note 10 


QoS 


varies 


3 







NOTE 1 : The MS shall not use value 0. 

NOTE 2: Shall contain the NSAPI for the requested PDP context 

NOTE 3: If the SwMI supports use of the QoS information element but does not support the use of secondary PDP 
contexts, and it receives an ATID value 101 2 it shall discard the remainder of this PDU and shall reject the 
MS's request with reject cause "Secondary PDP contexts not supported" (value 0001 101 1 2). 

NOTE 4: Shall be conditional on the value of Address Type Identifier in Demand (ATID): 

- when ATID = the information element shall be present; 

- for any other value of the ATID the information element shall not be present. 
NOTE 5: Shall be conditional on the value of Address Type Identifier in Demand (ATID): 

- when ATID = 5 (Primary NSAPI (secondary PDP context requested)) the information element shall be 
present; 

- for any other value of the ATID the information element shall not be present. 

NOTE 6: Shall contain the NSAPI of the primary PDP context from which the requested secondary PDP context 

derives its PDP address. 
NOTE 7: Shall be conditional on the value of bit 1 (LSB) of PCOMP negotiation: 

- when bit 1 of PCOMP negotiation = the information element shall not be present; 

- when bit 1 of PCOMP negotiation = 1 the information element shall be present. 
NOTE 8: Shall be conditional on the value bit 2 of PCOMP negotiation: 

- when bit 2 of PCOMP negotiation = the information element shall not be present; 

- when bit 2 of PCOMP negotiation = 1 the information element shall be present. 
NOTE 9: The default value shall be "OOOOhex". 

NOTE 10: The maximum length shall be 128 octets. 



NOTE: Some combinations of the SN-ACTIVATE PDP CONTEXT DEMAND PDU that include the QoS 
information element may be transmitted without fragmentation in SCH/HU. For example: 

■ requesting a primary PDP context with no conditional information elements, with no optional 
information elements apart from the the 1-bit version of the QoS information element, with a 
layer 2 reservation requirement and with an SSI (one unused SCH/HU bit); 
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■ requesting a secondary PDP context with no conditional information elements, with no optional 
information elements apart from the 48-bit version of the QoS information element with 
asymmetric QoS and no QoS filter, with no layer 2 reservation requirement and with an event label 
(two unused SCH/HU bits); 

■ requesting a primary PDP context, with no conditional information elements apart from the number 
of Van Jacobson compression state slots, with no optional information elements apart from the 
1-bit version of the optional QoS information element, with a layer 2 reservation requirement and 
with an event label (seven unused SCH/HU bits). 

28.4.4.3 SN-ACTIVATE PDP CONTEXT REJECT 

SN-ACTIVATE PDP CONTEXT REJECT PDU shall contain information elements as defined in table 28.25. 

• Message: SN-ACTIVATE PDP CONTEXT REJECT PDU 

• Response to: SN-ACTIVATE PDP CONTEXT DEMAND PDU 

• Response expected: 

• Short description: 

Table 28.25: SN-ACTIVATE PDP CONTEXT REJECT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-ACTIVATE PDP CONTEXT REJECT 


NSAPI 


4 


1 


M 




Activation reject cause 


8 


1 


M 




Protocol configuration options 


varies 


3 





see note 


NOTE: The maximum lengtli sliall be 128 octets. 



28.4.4.4 SN-DATA 

SN-DATA PDU shall contain information elements as defined in table 28.26. 

• Message: SN-DATA PDU 

• Response to: 

• Response expected: 

• Short description: SN-DATA PDU is used for acknowledged service. 

Table 28.26: SN-DATA PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 




M 


SN-DATA 


NSAPI 


4 




M 




PCOMP 


4 




M 




DCOMP 


4 




M 




N-PDU 


varies 




M 




NOTE: The N-PDU length is defined by the length of the lower layer PDU. There shall be no 0-bit after the 
N-PDU. 



£75/ 



994 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



28.4.4.4a SN-DATA-PRIORITY ACKNOWLEDGEMENT 

SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU shall contain information elements as defined in table 28.27. 

• Message: SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU 

• Response to: SN-DATA-PRIORITY REQUEST PDU 

• Response expected: 

• Short description: Used by SwMI in reply to request from the MS concerning data priority. 

Table 28.27: SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-DATA-PRIORITY 


Data priority sub-type 


4 


1 


M 


SN-DATA-PRIORITY ACKNOWLEDGEMENT 


Data priority request result 


1 


1 


M 




Data priority details 


24 


1 


M 




IVIS default data priority 


4 




C 


See note 


NOTE: This information element shall be present only if the data priority request result information element 

indicates "Request accepted". The value of the IVIS default data priority information element may differ 
from that requested by the MS in the SN-DATA-PRIORITY REQUEST PDU. 



28.4.4.4b SN-DATA-PRIORITY INFORMATION 

SN-DATA-PRIORITY INFORMATION PDU shall contain information elements as defined in table 28.28. 

• Message: SN-DATA-PRIORITY INFORMATION PDU 

• Response to: 

• Response expected: 

• Short description: Used by SwMI to send MS information about data priority. 

Table 28.28: SN-DATA-PRIORITY INFORMATION PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-DATA-PRIORITY 


Data priority sub-type 


4 


1 


M 


SN-DATA-PRIORITY INFORMATION 


Data priority details 


24 


1 


M 




MS default data priority flag 


1 


1 


M 


See note 1 


MS default data priority 


4 




C 


See note 2 


NOTE 1 : This information element should be set to "0" if this PDU is sent to a group or broadcast address. 
NOTE 2: This information element shall be present only if "MS default data priority flag" = 1 
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28.4.4.4c SN-DATA-PRIORITY REQUEST 

SN-DATA-PRIORITY REQUEST PDU shall contain information elements as defined in table 28.29. 

• Message: SN-DATA-PRIORITY REQUEST PDU 

• Response to: 

• Response expected: SN-DATA-PRIORITY ACKNOWLEDGEMENT PDU 

• Short description: Used by MS to request data priority change or information. 

Table 28.29: SN-DATA-PRIORITY REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-DATA-PRIORITY 


Data priority sub-type 


4 


1 


M 


SN-DATA-PRIORITY REQUEST 


Data priority request type 


4 


1 


M 





28.4.4.5 SN-DATA TRANSMIT REQUEST 

SN-DATA TRANSMIT REQUEST PDU shall contain information elements as defined in table 28.30. 

• Message: SN-DATA TRANSMIT REQUEST PDU 

• Response to: 



Response expected: 



SN-DATA TRANSMIT RESPONSE PDU (when SN-DATA TRANSMIT 
REQUEST PDU is sent by the MS) 



Short description: 

Table 28.30: SN-DATA TRANSMIT REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-DATA TRANSMIT REQUEST 


NSAPI 


4 


1 


M 




Logical link status 


1 


1 


M 


see note 1 


Enhanced 7i/4-DQPSK service (see note 5) 


1 


1 


M 


see note 1 


Resource request 


variable 




C 


see note 2 


SNDCP network endpoint identifier 


16 


2 





see note 3 


Reserved 


20 


2 





see note 4 


NOTE 1 : This information element has meaning only on uplink. The information element value shall be "0" on 

downlink in the present document. 
NOTE 2: For usage refer to clause 28.3.5.2a. Shall be conditional on the value of Enhanced 7t/4-DQPSK service 

information element: 

- when the Enhanced n/4-DQPSK service = 1 the Resource request information element shall be 
present; 

- when the Enhanced 7t/4-DQPSK service = the Resource request Information element shall not 
be present. 

NOTE 3: For usage refer to clause 28.3.3.3. 

NOTE 4: Shall not be used in protocol defined in the present document. 

NOTE 5: This was formerly known as the "enhanced service" information element. 



If MS supports the use of non-conforming PDCHs, the "channel advice flag" parameter in the MLE-UNITDATA 
request primitive containing this PDU should be set to "channel advice requested". 

NOTE: Fragmentation will occur if this PDU is sent in SCH-Q/RA with an SSI and SNEI 
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28.4.4.6 SN-DATA TRANSMIT RESPONSE 

SN-DATA TRANSMIT RESPONSE PDU shall contain information elements as defined in table 28.31. 
Message: SN-DATA TRANSMIT RESPONSE PDU 

Response to: SN-DATA TRANSMIT REQUEST PDU (MS to SwMI), SN-RECONNECT PDU 

Response expected: 
Short description: 

Table 28.31 : SN-DATA TRANSMIT RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-DATA TRANSMIT RESPONSE 


NSAPI 


4 


1 


M 




Accept/Reject 


1 


1 


M 




Transmit response reject cause 


8 




C 


see note 1 


SNDCP network endpoint identifier 


16 


2 





see note 2 


NOTE 1 : Shall be conditional on the value of the Accept/Reject information element: 

- when the Accept/Reject = the transmit response reject cause information element shall be 
present; 

- when the Accept/Reject = 1 the transmit response reject cause information element shall not be 
present. 

NOTE 2: For usage refer to clause 28.3.3.3. 



28.4.4.7 SN-DEACTIVATE PDP CONTEXT DEMAND 

SN-DEACTIVATE PDP CONTEXT DEMAND PDU shall contain information elements as defined in table 28.32. 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



SN-DEACTIVATE PDP CONTEXT DEMAND PDU 



SN-DEACTIVATE PDP CONTEXT ACCEPT PDU 



Table 28.32: SN-DEACTIVATE PDP CONTEXT DEMAND PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-DEACTIVATE PDP CONTEXT DEMAND 


Deactivation type 


8 


1 


M 




NSAPI 


4 




C 


see note 1 


SNDCP network endpoint identifier 


16 


2 





see note 2 


Reserved 


12 


2 





see note 3 


NOTE 1 : Shall be conditional on the value of the Deactivation type information element: 

- when the value of the Deactivation type = the NSAPI information element shall not be present; 

- when the value of the Deactivation type = 1 the NSAPI information element shall be present; 

- for all other values of the Deactivation type information element the NSAPI shall be present. 
NOTE 2: For usage, refer to clause 28.3.3.3. 

NOTE 3: Shall not be used in protocol defined in the present document. 
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28.4.4.8 SN-DEACTIVATE PDP CONTEXT ACCEPT 

SN-DEACTIVATE PDP CONTEXT ACCEPT PDU shall contain information elements as defined in table 28.33. 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



SN-DEACTIVATE PDP CONTEXT ACCEPT PDU 



SN-DEACTIVATE PDP CONTEXT DEMAND PDU 



Table 28.33: SN-DEACTIVATE PDP CONTEXT ACCEPT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-DEACTIVATE PDP CONTEXT ACCEPT 


Deactivation type 


8 


1 


M 




NSAPI 


4 




C 


see note 1 


SNDCP networl< endpoint identifier 


16 


2 





see note 2 


Reserved 


11 


2 





see note 3 


NOTE 1 : Shall be conditional on the value of Deactivation type information element: 

- when the Deactivation Type = the NSAPI information element shall not be present; 

- when the value of the Deactivation type = 1 the NSAPI information element shall be present; 

- for all other values of the Deactivation type information element the NSAPI shall be present. 
NOTE 2: For usage, refer to clause 28.3.3.3. 

NOTE 3: Shall not be used in protocol defined in the present document. 



28.4.4.9 SN-END OF DATA 

SN-END OF DATA PDU shall contain information elements as defined in table 28.34. 



Message: 
Response to: 
Response expected: 
Short description: 



SN-END OF DATA PDU 
-/SN-END OF DATA PDU 
-/SN-END OF DATA PDU 

Table 28.34: SN-END OF DATA PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-END OF DATA 


Immediate service change 


1 


1 


M 




Reserved 


41 


2 





see note 


NOTE: Shall not be used in protocol defined in the present document. 
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28.4.4.9a SN-MODIFY PDP CONTEXT REQUEST 

SN-MODIFY PDP CONTEXT REQUEST PDU shall contain information elements as defined in table 28.35. 

• Message: SN-MODIFY PDP CONTEXT REQUEST PDU 

• Response to: 

• Response expected: SN-MODIFY PDP CONTEXT RESPONSE PDU 

• Short description: 

Table 28.35: SN-MODIFY PDP CONTEXT REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-MODIFY 


Modify sub-type 


4 


1 


M 


SN-MODIFY PDP CONTEXT REQUEST 


NSAPI 


4 


1 


M 




QoS 


varies 


1 


M 





28.4.4.9b SN-MODIFY PDP CONTEXT RESPONSE 

SN-MODIFY PDP CONTEXT RESPONSE PDU shall contain information elements as defined in table 28.36. 



• Message: 

• Response to: 

• Response expected: 

• Short description: 



SN-MODIFY PDP CONTEXT RESPONSE PDU 



SN-MODIFY PDP CONTEXT REQUEST PDU 



Table 28.36: SN-MODIFY PDP CONTEXT RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-MODIFY 


Modify sub-type 


4 


1 


M 


SN-MODIFY PDP CONTEXT RESPONSE. 


NSAPI 


4 


1 


M 




Modification result 


1 


1 


M 


see note 1 


Modification reject cause 


8 




C 


see note 2 


PDU priority max 


3 




C 


see note 3 


QoS 


varies 




C 


see note 3 


NOTE 1 : "Modification rejected" means the PDP context remains unaltered. 

NOTE 2: Shall be present only if "modification result" has value "1 " (modification rejected). 

NOTE 3: Shall be present only if "modification result" has value "0" (modification applied). 
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28.4.4.9c SN-MODIFY PDP CONTEXT AVAILABILITY 

SN-MODIFY PDP CONTEXT AVAILABILITY PDU shall contain information elements as defined in table 28.37. 

• Message: SN-MODIFY PDP CONTEXT AVAILABILITY PDU 

• Response to: 

• Response expected: 

• Short description: 

Table 28.37: SN-MODIFY PDP CONTEXT AVAILABILITY PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-MODIFY 


Modify sub-type 


4 


1 


M 


SN-MODIFY PDP CONTEXT AVAILABILITY 


NSAPI 


4 


1 


M 




PDP context availability 


3 


1 


M 





28.4.4.9d SN-MODIFY PDP CONTEXT USAGE 

SN-MODIFY PDP CONTEXT USAGE PDU shall contain information elements as defined in table 28.38. 

• Message: SN-MODIFY PDP CONTEXT USAGE PDU 

• Response to: 

• Response expected: 

• Short description: 

Table 28.38: SN-MODIFY PDP CONTEXT USAGE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-MODIFY 


Modify sub-type 


4 


1 


M 


SN-MODIFY PDP CONTEXT USAGE. 


NSAPI 


4 


1 


M 




PDP context usage 


3 


1 


M 




Reserved 


9 


2 





Shall not be used in the present document. 



NOTE: This PDU is an exact fit in SCH-Q/RA when the reserved type 2 information element is included with an 
SSI and without a layer 2 reservation requirement. 
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28.4.4.10 SN-NOT SUPPORTED 

SN-NOT SUPPORTED PDU shall contain information elements as defined in table 28.39. 

• Message: SN-NOT SUPPORTED PDU 

• Response to: - Any individually addressed SN PDU 

• Response expected: 

• Short description: This PDU may be sent by the MS or the SwMI to indicate that the received SN 
PDU or the function indicated in the PDU is not supported by the peer entity. 

Table 28.39: SN-NOT SUPPORTED PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-NOT SUPPORTED 


Not supported SN PDU type 


4 


1 


M 





28.4.4.11 SN-PAGE REQUEST 

SN-PAGE REQUEST PDU shall contain information elements as defined in table 28.40. 

• Message: SN-PAGE REQUEST PDU 

• Response to: 

• Response expected: No response or SN-PAGE RESPONSE PDU 

• Short description: 

Table 28.40: SN-PAGE REQUEST PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-PAGE REQUEST 


NSAPI 


4 


1 


M 




Reply requested 


1 


1 


M 




SNDCP network endpoint identifier 


16 


2 





see note 


NOTE: For usage, refer to clause 28.3.3.3. 



£75/ 



1001 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



28.4.4.12 SN-PAGE RESPONSE 

SN-PAGE RESPONSE PDU shall contain information elements as defined in table 28.41. 

• Message: SN-PAGE RESPONSE PDU 

• Response to: SN-PAGE REQUEST PDU 

• Response expected: 

• Short description: 

Table 28.41 : SN-PAGE RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 




M 


SN-PAGE RESPONSE 


NSAPI 


4 




M 




PD service status 


1 




M 




Logical link status 


1 




M 




Enhanced 7t/4-DQPSK service (see note 4) 


1 




M 




Resource request 


varies 




C 


see note 1 


SNDCP network endpoint identifier 


16 


2 





see note 2 


Reserved 


18 


2 





see note 3 


NOTE 1 : For usage, refer to clause 28.3.5.2a. Shall be conditional on the value of Enhanced n/4-DQPSK 
service information element: 

- when the Enhanced n/4-DQPSK service = 1 the Resource request information element shall be 
present; 

- when the Enhanced 7t/4-DQPSK service = the Resource request Information element shall not be 
present. 

NOTE 2: For usage, refer to clause 28.3.3.3. 

NOTE 3: Shall not be used in protocol defined in the present document. 

NOTE 4: This was formerly known as the "enhanced service'" information element. 



If the MS supports the use of non-conforming PDCHs, the "channel advice flag" parameter in the MLE-UNITDATA 
request primitive containing this PDU should be set to "channel advice requested". 
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28.4.4.13 SN-RECONNECT 

SN-RECONNECT PDU shall contain information elements as defined in table 28.42. 



Message: 
Response to: 



SN-RECONNECT PDU 



Response expected: No response, SN-DATA TRANSMIT RESPONSE PDU or SN-DATA 

TRANSMIT REQUEST PDU 



Short description: 



Table 28.42: SN-RECONNECT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 


1 


M 


SN-RECONNECT 


Data to send 


1 


1 


M 




NSAPI 


4 




C 


see note 1 


Enhanced 7i/4-DQPSK service (see note 5) 


1 


1 


M 




Resource request 


varies 




C 


see note 2 


SNDCP network endpoint identifier 


16 


2 





see note 3 


Reserved 


19 


2 





see note 4 


NOTE 1 : Shall be conditional on the value of the Data to Send information element: 

- when the Data to send = 1 the NSAPI information element shall be present; 

- when the Data to send = the NSAPI information element shall not be present. 
NOTE 2: For usage, refer to clause 28.3.5.2a. Shall be conditional on the value of the 

Enhanced 7t/4-DQPSK service information element: 

- when the Enhanced 7i/4-DQPSK service = 1 the Resource request information element shall be 
present; 

- when the Enhanced 7i/4-DQPSK service = the Resource request information element shall not be 
present. 

NOTE 3: For usage, refer to clause 28.3.3.3. 

NOTE 4: Shall not be used in protocol defined in the present document. 

NOTE 5: This was formerly known as the "enhanced service" information element. 



If the MS supports the use of non-conforming PDCHs, the "channel advice flag" parameter in the MLE-UNITDATA 
request primitive containing this PDU should be set to "channel advice requested". 

28.4.4.14 SN-UNITDATA 

SN-UNITDATA PDU shall contain information elements as defined in table 28.43. 



Message: 
Response to: 
Response expected: 
Short description: 



SN-UNITDATA PDU 



SN-UNITDATA PDU is used for unacknowledged service. 
Table 28.43: SN-UNITDATA PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SN PDU type 


4 




M 


SN-UNITDATA 


NSAPI 


4 




M 




PCOMP 


4 




M 




DCOMP 


4 




M 




N-PDU 


varies 




M 




NOTE: The N-PDU length is defined by the length of the lower layer PDU. There shall be no 0-bit after the 
N-PDU. 
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28.4.5 SNDCP information elements coding 



28.4.5.1 Accept/Reject 

The Accept/Reject information element shall be encoded as defined in table 28.44. 

Table 28.44: Accept/Reject information element contents 



Information element 


Length 


Value 


Remark 


Accept/Reject 


1 





Request rejected by the SwMI 


1 


Request accepted by the SwMI 



28.4.5.2 Access point name index 

The Access point name index information element shall be encoded as defined in table 28.45. 

Table 28.45: Access point name index information element contents 



Information element 


Length 


Value 


Remark 


Access point name index 


16 


any 
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28.4.5.3 Activation reject cause 

The Activation reject cause information element shall be encoded as defined in table 28.46. 

Table 28.46: Activation reject cause information element contents 



Information element 



Length 



Value 



Remark 



Reject cause 



8 







10 



11 



12 



13 



14 



15 



16 



17 



19 



20 



21 



22 



23 



24 



25 



26 



27 



28 



29 



30 



31 



32 



33 



others 



Undefined 



MS not provisioned for Packet Data 



IPv4 not supported 



IPv6 not supported 



IPv4 dynamic address negotiation not supported 



IPv6 stateful address autoconfiguration not supported 



IPv6 stateless address autoconfiguration not supported 



Dynamic address pool empty 



Static address not correct 



Static address in use 



Static address not allowed 



Static IP address congestion 



TETRA Packet data not supported on this location area 



TETRA Packet data not supported on this network. 



Temporary rejection 



Packet Data IVIS Type not supported 



SNDCP version not supported 



IVIobile IPv4 not supported 



IVIobile IPv4 Co-located care of address not supported. 



IVIaximum number of PDP Contexts per ITSI exceeded. 



User authentication failed 



Activation rejected by external PDN 



Access point name index not correct 



Requested minimum peak throughput not available 



Scheduled access not supported 



Requested schedule not available 



Requested QoS not available 



Secondary PDP contexts not supported 



Primary PDP context does not exist 



Asymmetric QoS not supported 



Automatic QoS filter not supported 



Specified QoS filter not supported 



QoS filter type not supported 



QoS filter not available for primary PDP context 



Reserved 



28.4.5.4 Address Type Identifier in Demand 

The Address Type Identifier in Demand information element shall be encoded as defined in table 28.47. 
Table 28.47: Address Type Identifier in Demand information element contents 



Information element 


Length 


Value 


Remark 


Address Type Identifier in Demand 


3 





IPv4 Static Address 


1 


IPv4 Dynamic Address Negotiation 


2 


IPv6 


3 


IVIobile IPv4 Foreign Agent care of address requested 


4 


IVIobile IPv4 Co-located care-of address requested 


5 


Primary NSAPI (secondary PDP context requested) 


others 


Reserved 
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28.4.5.4a Asymmetrical QoS 

The asymmetrical QoS information element shall be encoded as defined in table 28.48. 

Table 28.48: Asymmetrical QoS information element contents 



Information element 


Length 


Value 


Remark 


Asymmetrical QoS 


1 





Symmetrical QoS 


1 


Asymmetrical QoS (separate uplink QoS and 
downlink QoS included) 



28.4.5.4 b Background class request 

The background class request information element shall be encoded as defined in table 28.49. 

Table 28.49: Background class request information element contents 



Information element 


Length 


Value 


Remark 


Background class request 


1 





Background class 


1 


Any data class 



28.4.5.5 BSD data compression parameters 

The BSD data compression parameters information element shall be encoded as defined in table 28.50. 

Table 28.50: BSD data compression parameters information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


BSD compression version 


3 


1 


M 




BSD dictionary size 


5 


1 


M 





28.4.5.6 BSD compression version 

The BSD compression version information element shall be encoded as defined in table 28.51. 

Table 28.51 : BSD compression version information element contents 



Information element 


Length 


Value 


Remark 


BSD compression version 


3 





Reserved 


1 


Version 1 


2 to 7 


Reserved 



28.4.5.7 BSD dictionary size 

The BSD dictionary size information element shall be encoded as defined in table 28.52. 

Table 28.52: BSD dictionary size information element contents 



Information element 


Length 


Value 


Remark 


BSD dictionary size 


5 


0to8 


Reserved 


9 to 16 


Length of largest code in bits 


17 to 31 


Reserved 
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28.4.5.7a CONTEXT_READY timer 

The CONTEXT_READY timer information element shall be encoded as defined in table 28.53. 

Table 28.53: CONTEXT READY timer information element contents 



Information element 


Length 


Value 


Remark 


CONTEXT_READY timer 


4 





Track the READY timer 


1 


200 ms 


2 


500 ms 


3 


700 ms 


4 


1 s 


5 


2s 


6 


3s 


7 


5s 


8 


10s 


9 


20 s 


10 


30 s 


11 


60s 


12 


120 s 


13 


180 s 


14 


300 s 


15 


Reserved 



28.4.5.7b Data class 

The Data class information element shall be encoded as defined in table 28.54. 

Table 28.54: Data class information element contents 



Information element 


Length 


Value 


Remark 


Data class 


3 





Bacl<ground 


1 


Telemetry 


2 


Real-time 


3 


Reserved 


4 


Reserved 


5 


Reserved 


6 


Reserved 


7 


Reserved 



28.4.5.7c Data priority details 

The Data priority details information element shall be encoded as defined in table 28.55. 

Table 28.55: Data priority details information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Network default data priority 


3 




M 




Layer 2 data priority lifetime 


6 




M 




Layer 2 data priority signalling delay 


3 




M 




Data priority random access delay factor 


3 




M 




Reserved 


9 




M 


Shall be set to "0". 



NOTE: The layer 2 data priority lifetime should normally be set to a greater time than the layer 2 data priority 
signalling delay. 
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28.4. 5.7d Data priority random access delay factor 

The Data priority random access delay factor information element shall be encoded as defined in table 28.56. 
Table 28.56: Data priority random access delay factor information element contents 



Information element 


Length 


Value 


Remark 


Data priority random access delay factor 


3 





Data priority random access delay factor = 


1 


Data priority random access delay factor = 1 


etc. 


etc. 


7 


Data priority random access delay factor = 7 



NOTE: The use of the data priority random access delay factor is defined in clauses 23.4.7.5.2 and 23.4.7.5.3. 

28.4. 5.7e Data priority request result 

The Data priority request result information element shall be encoded as defined in table 28.57. 

Table 28.57: Data priority request result information element contents 



Information element 


Length 


Value 


Remark 


Data priority request result 


1 





Request accepted (see note) 


1 


Request rejected 


NOTE: This means that the MS default data priority has been changed, but it need not be changed to the 
value requested by the IVIS. 



28.4. 5.7f Data priority request type 

The Data priority request type information element shall be encoded as defined in table 28.58. 

Table 28.58: Data priority request type information element contents 



Information element 


Length 


Value 


Remark 


Data priority request type 


4 





Set MS default data priority 


1 


Set MS default data priority 1 


etc. 


etc. 


7 


Set MS default data priority 7 


8 


Set MS default data priority to track network 
default data priority 


9 


Report Network and MS default data priorities 


10 


Reserved 


etc. 


etc. 


15 


Reserved 



28.4. 5.7g Data priority sub-type 

The data priority sub-type information element shall be encoded as defined in table 28.59. 

Table 28.59: Data priority sub-type information element contents 



Information element 


Length 


Value 


Remark 


Data priority sub-type 


4 





SN-DATA-PRIORITY ACKNOWLEDGEMENT 


1 


SN-DATA-PRIORITY INFORMATION 


2 


SN-DATA-PRIORITY REOUEST 


3 


Reserved 


etc. 


etc. 


15 


Reserved 
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28.4.5.8 Data to send 

The Data to send information element shall be encoded as defined in table 28.60. 

Table 28.60: Data to Send information element contents 



Information element 


Length 


Value 


Remark 


Data to send 


1 





No data to send 


1 


SN-DATA PDU or SN-UNITDATA PDU awaiting 
transmission on uplinl< 



28.4.5.8a Delay class 

The Delay class information element shall be encoded as defined in table 28.61. 

Table 28.61 : Delay class information element contents 



Information element 


Length 


Value 


Remark 


Delay class (see note) 


2 





Low 


1 


Moderate 


2 


High 


3 


Unpredictable 


NOTE: Delay classes are defined in table 28.10. 



28.4.5.9 DCOMP 

The DCOMP information element shall be encoded as defined in table 28.62. 

Table 28.62: DCOMP information element contents 



Information element 


Length 


Value 


Remark 


DCOIVIP 


4 





No compression 


1 


ITU-T Recommendation V.42bis [27] 


2 


BSD compression 


3 


Predictor compression 


4 


BSD uncompressible packet 


Otiiers 


Reserved for further compression algorithms(a list of fixed 
or negotiated algorithms e.g. pkzip, fax, MPEG) 



28.4.5.10 DCOMP negotiation 

The DCOMP negotiation information element shall be encoded as defined in table 28.63. 

Table 28.63: DCOMP negotiation information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


DCOMP 


4 


1 


M 




Data compression parameters 


varies 




C 


see note 


NOTE: Shall be conditional on the value of DCOMP: 

- when DCOMP = 0, 3 or 4 no data compression parameters are present; 

- when DCOMP = 1 , "ITU-T Recommendation 4.2bis data compression request parameters" shall be present; 

- when DCOMP = 2, "BSD data compression parameters" shall be present. 
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28.4.5.11 Deactivation type 

The Deactivation type information element shall be encoded as defined in table 28.64. 

Table 28.64: Deactivation type information element contents 



Information element 


Length 


Value 


Remark 


Deactivation type 


8 





Deactivate all NSAPIs 


1 


Deactivate NSAPI given in the PDU 


others 


Reserved 



28.4.5.11a Diffserv filter 

The Diffserv filter information element shall be encoded as defined in table 28.65. 

Table 28.65: Diffserv filter information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


DSCP 


8 




M 


See note 1 


Reserved 


8 




M 


See note 2 


NOTE 1 : Contains a differentiated services code point value (see RFC 2474 [43] and RFC 2475 [44]). 
NOTE 2: Shall be set to zero in the present document. 



28.4.5.1 2 Enhanced 7t/4-DQPSK service 

The Enhanced 7t/4-DQPSK service information element shall be encoded as defined in table 28.66. 

Table 28.66: Enhanced 7i/4-DQPSK service information element contents 



Information element 


Length 


Value 


Remark 


Enhanced 7i/4-DQPSK service 


1 





Enhanced 7t/4-DOPSK service not requested 


1 


Enhanced 7i/4-DQPSK service requested 



NOTE: This was formerly known as the "enhanced service" information element. 

28.4.5.1 3 Immediate service change 

The Immediate service change information element shall be encoded in table 28.67. 

Table 28.67: Immediate service change information element contents 



Information element 


Length 


Value 


Remark 


Immediate service change 


1 





Not indicated 


1 


Indicated 



28.4.5.14 IP address I pv4 

The IP address Ipv4 information element shall be encoded as defined in table 28.68. 

Table 28.68: IP address IPv4 information element contents 



Information element 


Length 


Value 


Remark 


IP address Ipv4 


32 


any 
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28.4.5.1 5 Largest header size in octets that may be compressed 

The Largest header size in octets that may be compressed information element shall be encoded as defined in 
table 28.69. 

Table 28.69: Largest header size in octets that may be compressed information element contents 



Information element 


Length 


Value 


Remark 


Largest header in octets that may be 
compressed 


8 


to 255 


The size of the largest header in octets. 



28.4.5.1 5a Layer 2 data priority lifetime 

The Layer 2 data priority lifetime information element shall be encoded as defined in table 28.70. 

Table 28.70: Layer 2 data priority lifetime information element contents 



Information element 


Length 


Value 


Remark 


Layer 2 data priority lifetime 


6 





Reserved 


1 


2 multiframes 


2 


4 multiframes 


etc. 


etc. 


63 


126 multiframes 



28.4.5.1 5b Layer 2 data priority signalling delay 

The Layer 2 data priority signalling delay information element shall be encoded as defined in table 28.71. 
Table 28.71 : Layer 2 data priority signalling delay information element contents 



Information element 


Length 


Value 


Remark 


Layer 2 data priority signalling delay 


3 





6 TDMA frames 


1 


9 TDIVIA frames 


2 


12 TDMA frames 


3 


18 TDIVIA frames 


4 


27 TDMA frames 


5 


36 TDMA frames 


6 


54 TDMA frames 


7 


90 TDMA frames 



28.4.5.1 6 Logical link status 

The Logical link status information element shall be encoded as defined in table 28.72. 

Table 28.72: Logical link status information element contents 



Information element 


Length 


Value 


Remark 


Logical link status 


1 





Advanced link not connected 


1 


Advanced link connected 
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28.4.5.17 Maximum interval between full headers 

The Maximum interval between full headers indicates the maximum number of compressed non-TCP headers that can 
be sent between full headers. The information element shall be encoded as defined in table 28.73. 

Table 28.73: Maximum interval between full headers information element contents 



Information element 


Length 


Value 


Remark 


Maximum interval between full headers 


8 





There is no limit to the number of consecutive 
compressed headers. 


1 to 255 


IVIaximum 16 x value consecutive compressed 
headers. 



28.4.5.18 Maximum time interval between full headers 

The Maximum time interval between full headers indicates the maximum interval between full headers. The 
information element shall be encoded as defined in table 28.74. 

Table 28.74: Maximum time interval between full headers information element contents 



Information element 


Length 


Value 


Remark 


IVIaximum time interval between full headers 


8 





Infinity. 


1 to 255 


Compressed headers may not be sent more than 5 
X value s after sending the last full header. 



28.4.5.19 Maximum transmission unit 

The Maximum transmission unit information element shall be encoded as defined in table 28.75. 

Table 28.75: Maximum Transmission Unit information element contents 



Information element 


Length 


Value 


Remark 


Maximum transmission unit 


3 





Reserved 


1 


296 octets 


2 


576 octets 


3 


1 006 octets 


4 


1 500 octets 


5 


2 002 octets 


6 


Reserved 


7 


Reserved 
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28.4.5.19a Mean active throughput 

The Mean active throughput information element shall be encoded as defined in table 28.76. 

Table 28.76: Mean active throughput information element contents 



Information element 


Length 


Value 


Remark 


Mean active throughput 


4 





No value given 


1 


< 1 000 octets s"' 


2 


> 1 000 octets s"' 


3 


> 2 000 octets s' 


4 


> 4 000 octets s"' 


5 


> 8 000 octets s"' 


6 


> 16 000 octets s"' 


7 


> 32 000 octets s"' 


8 


> 64 000 octets s"' 


9 


Reserved 


etc. 


etc. 


15 


Reserved 



28.4.5.19b Mean throughput 

The Mean throughput information element shall be encoded as defined in table 28.77. 

Table 28.77: Mean throughput information element contents 



Information element 


Length 


Value 


Remark 


Mean throughput 


5 





No value given 


1 


1 00 octets h"' 


2 


200 octets h"' 


3 


500 octets h"' 


4 


1 000 octets h' 


5 


2 000 octets h' 


6 


5 000 octets h' 


7 


10 000 octets h' 


8 


20 000 octets h' 


9 


50 000 octets h' 


10 


100 000 octets h"' 


11 


200 000 octets h"' 


12 


500 000 octets h"' 


13 


1 000 000 octets h' 


14 


2 000 000 octets h' 


15 


5 000 000 octets h' 


16 


1 000 000 octets h' 


17 


20 000 000 octets h' 


18 


50 000 000 octets h' 


19 


Reserved 


etc. 


etc. 


30 


Reserved 


31 


Best effort. 
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28.4.5.19c Minimum peak throughput 

The Minimum peak throughput information element shall be encoded as defined in table 28.78. 

Table 28.78: Minimum peak throughput information element contents 



Information element 


Length 


Value 


Remark 


Minimum peal< throughput 


4 





No value given 


1 


< 1 000 octets s"' 


2 


> 1 000 octets s"' 


3 


> 2 000 octets s' 


4 


> 4 000 octets s' 


5 


> 8 000 octets s' 


6 


> 1 6 000 octets s"' 


7 


> 32 000 octets s"' 


8 


> 64 000 octets s"' 


9 


Reserved 


etc. 


etc. 


15 


Reserved 



28.4.5.1 9d Modification reject cause 

The modification reject cause information element shall be encoded as defined in table 28.79. 

Table 28.79: Modification reject cause information element contents 



Information element 


Length 


Value 


Remark 


IVIodification reject cause 


8 





Undefined 


14 


Temporary rejection 


23 


Requested minimum peak throughput not available 


24 


Scheduled access not supported 


25 


Requested schedule not available 


26 


Requested QoS not available 


27 


Secondary PDP contexts not supported 


28 


Primary PDP context does not exist 


29 


Asymmetric QoS not supported 


30 


Automatic QoS filter not supported 


31 


Specified QoS filter not supported 


32 


QoS filter type not supported 


33 


QoS filter not available for primary PDP context 


others 


Reserved 



28.4.5.1 9e Modification result 

The modification result information element shall be encoded as defined in table 28.80. 

Table 28.80: Modification result information element contents 



Information element 


Length 


Value 


Remark 


Modification result 


1 





Modification applied 


1 


Modification rejected (PDP context remains unmodified) 
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28.4.5.1 9f Modify sub-type 

The modify sub-type information element shall be encoded as defined in table 28.81. 

Table 28.81 : Modify sub-type information element contents 



Information element 


Length 


Value 


Remark 


Modify sub-type 


4 





SN-MODIFY PDP CONTEXT REQUEST 


1 


SN-MODIFY PDP CONTEXT RESPONSE 


3 


SN-MODIFY PDP CONTEXT AVAILABILITY 


4 


SN-MODIFY PDP CONTEXT USAGE 


etc. 


etc. 


15 


Reserved 



28.4.5.1 9g MS default data priority 

The MS default data priority information element shall be encoded as defined in table 28.82. 

Table 28.82: MS default data priority information element contents 



Information element 


Length 


Value 


Remark 


MS default data priority 


4 





MS default data priority = 


1 


MS default data priority = 1 


etc. 


etc. 


7 


MS default data priority = 7 


8 


MS default data priority = Network default data 
priority (see note). 


9 


Reserved 


etc. 


etc. 


15 


Reserved 


NOTE: When this value is set, the MS default data priority tracks the value of the network default data priority. 



28.4.5.1 9h MS default data priority flag 

The MS default data priority flag information element shall be encoded as defined in table 28.83. 

Table 28.83: MS default data priority flag information element contents 



Information element 


Length 


Value 


Remark 


MS default data priority flag 


1 





MS default data priority not included 


1 


MS default data priority included 



28.4.5.1 9i Network default data priority 

The Network default data priority information element shall be encoded as defined in table 28.84. 

Table 28.84: Network default data priority information element contents 



Information element 


Length 


Value 


Remark 


Network default data priority 


3 





Network default data priority = 


1 


Network default data priority = 1 


etc. 


etc. 


7 


Network default data priority = 7 
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28.4.5.20 Not supported SN PDU type 

The Not supported SN PDU type information element shall be encoded as defined in table 28.85. 

Table 28.85: Not supported SN PDU type information element contents 



Information element 


Length 


Value 


Remark 


SN PDU type 


4 





SN-ACTIVATE PDP CONTEXT DEMAND 
SN-ACTIVATE PDP CONTEXT ACCEPT 


1 


SN-DEACTIVATE PDP CONTEXT ACCEPT 


2 


SN-DEACTIVATE PDP CONTEXT DEMAND 


3 


SN-ACTIVATE PDP CONTEXT REJECT 


4 


SN-UNITDATA 


5 


SN-DATA 


6 


SN-DATA TRANSMIT REOUEST 


7 


SN-DATA TRANSMIT RESPONSE 


8 


SN-END OF DATA 


9 


SN-RECONNECT 


10 


SN-PAGE REQUEST (SwMI to MS) 
SN-PAGE RESPONSE (MS to SwMI) 


11 


Reserved 


12 


SN-DATA PRIORITY 


13 


SN-MODIFY 


others 


Reserved 



28.4.5.21 N-PDU 

The N-PDU information element shall be encoded as defined in table 28.86. 

Table 28.86: N-PDU information element contents 



Information element 


Length 


Value 


Remark 


N-PDU 


varies 


any 


The length of a N-PDU may range from bits up to the Maximum 
transmission unit size, which is set at context activation. 



28.4.5.22 NSAPI 

The NSAPI information element shall be encoded as defined in table 28.87. 

Table 28.87: NSAPI information element contents 



Information element 


Length 


Value 


Remark 


NSAPI 


4 





Reserved 


1 to 14 


Dynamically allocated 


15 


Reserved 



28.4.5.23 Number of compression state slots, TCP 

The Number of compression state slots, TCP indicates the maximum value of a context identifier in the space of context 
identifiers allocated for TCP. The information element shall be encoded as defined in table 28.88. 

Table 28.88: Number of compression state slots, TCP information element contents 



Information element 


Length 


Value 


Remark 


Number of compression state slots, TCP 


8 


to 255 


The value implies having one context. 
It is recommended that value is not used. 
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28.4.5.24 Number of compression state slots, non-TCP 

The Number of compression state slots, non-TCP indicates the maximum value of a context identifier in the space of 
context identifiers allocated for non-TCP. The information element shall be encoded as defined in table 28.89. 

Table 28.89: Number of compression state slots, non-TCP information element contents 



Information element 


Length 


Value 


Remark 


Number of compression state slots, 
non-TCP 


16 


to 65 535 


The value implies having one context. 
It is recommended that value is not used. 



28.4.5.25 Number of Van Jacobson compression state slots 

The number of Van Jacobson compression state slots information element shall be encoded as defined in table 28.90. 
Table 28.90: Number of Van Jacobson compression state slots information element contents 



Information element 


Length 


Value 


Remark 


Number of Van Jacobson compression 
state slots 


8 


2 to 255 


It is recommended that values and 1 are not 
used. 



28.4.5.26 Packet data MS Type 

The Packet data MS Type information element shall be encoded as defined in table 28.91. 

Table 28.91 : Packet data MS Type information element contents 



Information element 


Length 


Value 


Remark 


Packet data IVIS type 


4 





Type A 


1 


Type B 


2 


TypeC 


3 


Type D 


4 


Type E 


5 


Type F 


others 


Reserved 



28.4.5.27 PCOMP 

The PCOMP information element shall be encoded as defined in table 28.92. 

Table 28.92: PCOMP information element contents 



Information element 


Length 


Value 


Remark 


PCOMP 


4 





No compression 


1 


Van Jacobson compressed TCP/IP 


2 


Van Jacobson non-compressed TCP/IP 


3 


FULL HEADER 


4 


COMPRESSED TCP 


5 


COMPRESSED TCP NODELTA 


6 


COMPRESSED NON TCP 


7 


COMPRESSED RTP 8 


8 


COMPRESSED RTP 16 


9 


COMPRESSED UDP 8 


10 


COMPRESSED UDP 16 


11 


CONTEXT STATE 


others 


For further standardization (a list of fixed or 
negotiated algorithms e.g. IPv6) 
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28.4.5.28 PCOMP negotiation 

The PCOMP negotiation information element shall be encoded as defined in table 28.93. 

Table 28.93: PCOMP negotiation information element contents 



Information element 


Length 


Value 


Remark 


PCOMP negotiation 


8 


bit 1 (LSB) 


Van Jacobson TCP/IP header compression 
(IETF RFC 1144(29]) 


bit 2 


IP header compression (IETF RFC 2507 [35]) 
Enable use of PCOMP values: FULL HEADER, 
COMPRESSED TCP, 
COMPRESSED TCP NODELTA, 
COMPRESSED NON TCP, 
CONTEXT STATE (see note 1 ) 


bit 3 


Enable use of PCOMP values: COMPRESSED RTP 8, 
COMPRESSED RTP 16, COMPRESSED UDP 8, 
COMPRESSED UDP 16 and 
CONTEXT_STATE (IETF RFC 2508 [36]) 
(see notes 1 and 2) 


bit 4 


Reserved 


bit 5 


Reserved 


bite 


Reserved 


bit 7 


Reserved 


bit 8 (MSB) 


Reserved 


NOTE 1 : Bit 3 not set - "CONTEXT STATE" shall only be used to synchronize TCP context identities - 

clause 10.2 RFC 2507 [35]; 

Bit 3 set - "CONTEXT_STATE" may also be used to synchronize UDP_8 and UDP_1 6 context 

identities - clause 3.3.5 RFC 2508 [36]. 
NOTE 2: This bit shall be conditional on bit 2 and shall only be set to 1 if bit 2 is also set to 1 . 



28.4.5.29 PD service status 

The PD service status information element shall be encoded as defined in table 28.94. 

Table 28.94: PD service status information element contents 



Information element 


Length 


Value 


Remark 


PD service status 


1 





Temporarily unavailable for PD service 


1 


Available for PD service 



28.4.5.29a PDP context availability 

The PDP context availability information element shall be encoded as defined in table 28.95. 

Table 28.95: PDP context availability information element contents 



Information element 


Length 


Value 


Remark 


PDP context availability 


3 





PDP context available for use 


1 


Schedule suspended 


2 


Reserved 


etc. 


etc. 


7 


Reserved 



£75/ 



1018 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



28.4.5.29b PDP context usage 

The PDP context usage information element shall be encoded as defined in table 28.96. 

Table 28.96: PDP context usage information element contents 



Information element 


Length 


Value 


Remark 


PDP context usage 


3 





Use of schedule paused 


1 


Use of PDP context paused 


2 


Reserved 


etc. 


etc. 


7 


Reserved 



28.4.5.30 PDU priority max 

The PDU priority max information element shall be encoded as defined in table 28.97. 

Table 28.97: PDU priority max information element contents 



Information element 


Length 


Value 


Remark 


PDU priority max 


3 





Lowest PDU priority 


etc. 


etc. 


7 


Highest PDU priority 



28.4.5.30a Port 

The port information element shall be encoded as defined in table 28.98. 

Table 28.98: Port information element contents 



Information element 


Length 


Value 


Remark 


Port 


16 


Any 


See note 


NOTE: 


Shall contain a port number in the range to 65535. 
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28.4.5.31 Protocol configuration options 

The Protocol configuration options information element shall be encoded as defined in table 28.99. 

Table 28.99: Protocol configuration options information element contents 



Information element 


Length 


C/O/M 


Value 


Remark 


Configuration protocol 


4 


M 


OOOO2 


PPP 

All other values are interpreted as PPP in 
this version of the protocol 


Protocol identity 


16 


M 




see notes 1 and 3 


Length of protocol identity contents 


8 


M 




see notes 3 and 4 


Protocol identity contents 


varies 


M 




see notes 2 and 3 


NOTE 1 : Contains the hexadecimal coding of the configuration protocol identifier as defined in RFC 3232 [38]. 
Bit 8 of the first octet of the protocol identifier information element shall contain the most significant bit 
and bit 1 of the second octet of the protocol identifier information element shall contain the least 
significant bit. 
At least the following protocol identifiers shall be supported in this version of the protocol: 

- C023H = (PAP); and 

- C223H (CHAP). 

The support of other protocol identifiers is implementation dependent and outside the scope of the 
present document. If the configuration protocol options list contains a protocol identifier that is not 
supported by the receiving entity the corresponding unit shall be discarded. 

NOTE 2: The protocol identifier contents information element of each set corresponds to a "Packet" as defined 
in RFC 1661 [30] that is stripped off the "Protocol field" and the "Padding" octets (i.e. the protocol 
identifier contents field is constructed from fields "Code", "Identifier", "Length" and "Data" as described 
in RFC 1661 [30]). The detailed coding of the protocol identifier contents field is specified in the RFC 
that is associated with the protocol identifier of that unit. 

NOTE 3: These information elements shall be repeated as a set for each protocol. 

NOTE 4: The "length of protocol identity contents" information element shall indicate the length of the "protocol 
identity contents" in octets. 



28.4.5.31a QoS 

The QoS information element shall be encoded as defined in table 28.100. 

Table 28.100: QoS information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Background class request 


1 


1 


M 




CONTEXT READY timer 


4 




C 


See note 1 


Asymmetrical QoS 


1 




C 


See note 1 


QoS set 


20 




c 


See notes 1 and 2 


QoS set 


20 




c 


See note 3 


QoS filter included 


1 




c 


See note 1 


QoS filter 


varies 




c 


See notes 1 and 4 


Scheduled access information included 


1 




c 


See notes 1 and 5 


Scheduled access 


varies 




c 


See note 6 


NOTE 1 : This information element shall be present only if "background class request" value is equal to "any data 

class". 
NOTE 2: If "asymmetrical QoS" value is equal to "symmetrical QoS" this information element specifies a 

common uplink and downlink QoS; if "asymmetrical QoS" value is equal to "asymmetrical QoS" it 

specifies only the uplink QoS. 
NOTE 3: This information element shall be present only if "asymmetrical QoS" value is equal to "asymmetrical 

QoS" and specifies the downlink QoS. 
NOTE 4 This information element shall be set to "QoS filter not included" if the QoS information element relates 

to a primary PDP context. 
NOTE 5: This information element shall be present only if "QoS filter included" value is equal to "QoS filter 

included". See clause 28.3.9 for usage. 
NOTE 6: If the SwMI does not support a schedule on this PDP context, it shall set "scheduled 

access information included" value to "not included". 
NOTE 7: This information element shall be present only if "scheduled access information included" value is 

equal to "included". 
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Information element 


Length 


Type 


C/O/M 


Remark 


QoS filter operation 


2 


1 


M 




OoS filter type 


4 


1 


M 




Port 


16 




C 


See notes 1 and 2 


Port 


16 




C 


See notes S and 4 


Diffserv filter 


16 




c 


See note 5 


Reserved 


16 




c 


See note 6 


Reserved 


16 




c 


See note 7 


NOTE 1 
NOTE 2 

NOTES 
NOTE 4 
NOTES 
NOTE 6 
NOTES 


This information element shall be present only if "QoS filter type" has a value in the range 1 to 6. 

If "QoS filter type " has a value in the range 1 to S this information element shall contain a port number. 

If the "QoS filter type" has a value in the range 4 to 6, this information element shall contain the lower 

limit of a range of port numbers. 

This information element shall be present only if "QoS filter type" has a value in the range 4 to 6. 

This information element shall contain the upper limit of a range of port numbers. 

This information element shall be present only if "QoS filter type" has value 7. 

This information element shall be present only if "QoS filter type" has a value in the range S to 15. 

This information element shall be present only if "QoS filter type" has a value in the range 12 to 15. 



28.4.5.31 c QoS filter included 

The QoS filter included information element shall be encoded as defined in table 28.102. 

Table 28.102: QoS filter included information element contents 



Information element 


Length 


Value 


Remark 


QoS filter included 


1 





QoS filter not included 


1 


QoS filter included 



28.4.5.31 d QoS filter operation 

The QoS filter operation information element shall be encoded as defined in table 28.103. 

Table 28.103: QoS filter operation information element contents 



Information element 


Length 


Value 


Remark 


QoS filter operation 


2 





Add this QoS filter to any existing QoS filter for 
this PDP context 


1 


Replace any existing QoS filter for this PDP 
context by this QoS filter 


2 


Remove this QoS filter from this PDP context 


S 


Reserved 
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The port type information element shall be encoded as defined in table 28.104. 

Table 28.104: Port type information element contents 
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Information element 


Length 


Value 


Remark 


Port type 


4 





Use automatic QoS filter for this PDP context until the 
QoS filter for this PDP context is replaced 


1 


All types of port 


2 


UDP ports 


3 


TCP ports 


4 


Range of all types of port 


5 


Range of UDP ports 


6 


Range of TCP ports 


7 


Diffserv filter 


8to15 


Reserved 



28.4.5.31 f QoS set 

The QoS set information element shall be encoded as defined in table 28.105. 

Table 28.105: QoS set information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Data class 


3 




M 




IVIinimum peak throughput 


4 




M 




Mean throughput 


5 




M 




Mean active throughput 


4 




M 




Delay class 


2 




M 




Reliability class 


2 




M 





28.4.5.32 READY timer 

The READY timer information element shall be encoded as defined in table 28.106. 

Table 28.106: READY timer information element contents 



Information element 


Length 


Value 


Remark 


READY timer 


4 





Reserved 


1 


200 ms 


2 


500 ms 


3 


700 ms 


4 


1 s 


5 


2s 


6 


3s 


7 


5s 


8 


10s 


9 


20 s 


10 


30 s 


11 


60s 


12 


120 s 


13 


180 s 


14 


300 s 


15 


Reserved 
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28.4.5.32a Reliability class 

The Reliability class information element shall be encoded as defined in table 28.107. 

Table 28.107: Reliability class information element contents 



Information element 


Length 


Value 


Remark 


Reliability class (see note) 


2 





Low 


1 


Moderate 


2 


High 


3 


Reserved 


NOTE: Reliability classes are defined in table 28.11. 



28.4.5.33 Reply requested 

The Reply requested information element shall be encoded as defined in table 28.108. 

Table 28.108: Reply requested information element contents 



Information element 


Length 


Value 


Remark 


Reply requested 


1 





SNDCP response not requested 


1 


SNDCP response requested 
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28.4.5.34 Resource request 

The resource request information element shall be coded as defined in table 28.109. This information element refers 
only to 7t/4-DQPSK resources. 

Table 28.109: Resource request information element contents 



Information element 


Length 


C/O/M 


Value 


Remark 


Connection symmetry 


1 


M 





Symmetric 7i/4-DQPSK connection 


1 


Asymmetric 7i/4-DOPSK connection 


Data transfer throughput 
(mean value) 


3 


M 


OOO2 


Network dependent minimum (see note 1) 


001 2 


1/32 of maximum 


01 O2 


1/16 of maximum 


0112 


1/8 of maximum 


1002 


1/4 of maximum 


1012 


1/2 of maximum 


1102 


Reserved 


1112 


Maximum 


Number of 7i/4-DQPSK timeslots 

on uplink or 

on uplink and downlink 


2 


M 


002 


1 timeslot (see note 2) 


012 


2 timeslots 


102 


3 timeslots 


112 


4 timeslots 


Number of 7i/4-DQPSK timeslots 
on downlink 


2 


C 


002 


1 timeslot (see note 3) 


012 


2 timeslots 


102 


3 timeslots 


112 


4 timeslots 


Full 71/4-DQPSK capability on 
uplink 


2 


M 


002 


1 timeslot (see note 4) 


012 


2 timeslots 


102 


3 timeslots 


112 


4 timeslots 


Full 71/4-DQPSK capability on 
downlink 


2 


M 


002 


1 timeslot (see note 4) 


012 


2 timeslots 


102 


3 timeslots 


112 


4 timeslots 


NOTE 1 : The BS may use a control channel as a general packet data channel, supporting advanced links for 

many IVISs, where each MS may be offering/receiving data packets at a low rate or intermittently. This 

parameter gives the BS the necessary information for planning its resource allocations. 
NOTE 2: In case of symmetric connection (i.e. Connection symmetry information element set to "0") the 

Number of 7i/4-DQPSK timeslots on uplink information element indicates the number of slots both on 

uplink and downlink direction. 
NOTE 3: Shall be conditional on the value of the Connection symmetry information element. The information 

element is present only for asymmetric connection (i.e. Connection symmetry information element set 

to"1"). 
NOTE 4: This information element indicates MS's capability to handle physical resources to the indicated 

direction. 
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28.4.5.35 RESPONSE_WAIT timer 

The RESPONSE_WAIT timer information element shall be encoded as defined in table 28.1 10. 

Table 28.110: RESPONSE WAIT timer information element contents 



Information element 


Length 


Value 


Remark 


RESPONSE_WAIT timer 


4 





400 ms 


1 


600 ms 


2 


800 ms 


3 


1 s 


4 


2s 


5 


3s 


6 


4s 


7 


5s 


8 


10s 


9 


15s 


10 


20 s 


11 


30 s 


12 


40 s 


13 


50 s 


14 


60s 


15 


Reserved 
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28.4.5.35a Scheduled access 

The scheduled access information element shall be encoded as defined in table 28.11 1. 

Table 28.1 1 1 : Scheduled access information element contents 



Information element 


Length 


C/O/M 


Value 


Remark 


Schedule repetition period 


10 


M 





Reserved 


1 


Reserved 


etc. 


etc. 


3 


Reserved 


4 


4 slot durations (see note 1 ) 


5 


5 slot durations 


etc. 


etc. 


706 


706 slot durations (10,00s) 


707 


Reserved 


etc. 


etc. 


1 023 


Reserved 


Schedule timing error 


3 


M 





< 1 slot duration (see note 1 ) 


1 


< 2 slot durations 


2 


< 4 slot durations 


3 


< 8 slot durations 


4 


< 16 slot durations 


5 


< 32 slot durations 


6 


< 64 slot durations 


7 


< 128 slot durations 


Scheduled number of SN-DATA or 
SN-UNITDATA PDUs per grant 


3 


M 





Reserved 


1 


1 


2 


2 


etc. 


etc. 


7 


7 


Scheduled SN-DATA or 
SN-UNITDATA PDU size 
(see note 2) 


12 


C 





Reserved 


1 


1 octets 


2 


2 octets 


etc. 


etc. 


2 002 


2 002 octets 


2 003 


Reserved 


etc. 


etc. 


4 095 


Reserved 


NOTE 1 : One slot has a duration of 85/6 ms. 

NOTE 2: This information element shall be present as many times as indicated by the "Scheduled number of 
SN-DATA or SN-UNITDATA PDUs per grant" information element. 



28.4.5.35b Scheduled access information included 

The "Scheduled access information included" information element shall be encoded as defined in table 28. 112. 
Table 28.112: Scheduled access information included information element contents 



Information element 


Length 


Value 


Remark 


Scheduled access information included 


1 





Not included 


1 


Included 
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28.4.5.36 SNDCP version 

The SNDCP version information element shall be encoded as defined in table 28. 1 13. 

Table 28.113: SNDCP version information element contents 



Information element 


Length 


Value 


Remark 


SNDCP version 


4 





Reserved 


1 


The first version of the TETRA Pacl<et Data specification 


others 


Reserved 



28.4.5.37 SNDCP network endpoint identifier 

The SNDCP network endpoint identifier information element shall be encoded as defined in table 28.1 14. 
Table 28.114: SNDCP endpoint identifier information element contents 



Information element 


Length 


Value 


Remark 


SNDCP endpoint identifier 


16 







28.4.5.38 SN PDU type 

The PDU type information element shall be encoded as defined in table 28. 115. 

Table 28.115: SN PDU type information element contents 



Information element 


Length 


Value 


Remark 


SN PDU type 


4 





SN-ACTIVATE PDP CONTEXT DEMAND (MS to SwMI) 
SN-ACTIVATE PDP CONTEXT ACCEPT (SwMI to MS) 


1 


SN-DEACTIVATE PDP CONTEXT ACCEPT 


2 


SN-DEACTIVATE PDP CONTEXT DEMAND 


3 


SN-ACTIVATE PDP CONTEXT REJECT 


4 


SN-UNITDATA 


5 


SN-DATA 


6 


SN-DATA TRANSMIT REOUEST 


7 


SN-DATA TRANSMIT RESPONSE 


8 


SN-END OF DATA 


9 


SN-RECONNECT 


10 


SN-PAGE REOUEST (SwMI to MS) 
SN-PAGE RESPONSE (MS to SwMI) 


11 


SN-NOT SUPPORTED 


12 


SN-DATA PRIORITY, see "Data priority sub-type" 
(clause 28.4.5.7g) for definition of SN PDU sub-type. 


13 


SN-MODIFY, see "Modify sub-type" (clause 28.4.5. 19f) for 
definition of SN PDU sub-type 


Others 


Reserved 
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28.4.5.39 STANDBY timer 

The STANDBY timer information element shall be encoded as defined in table 28. 116. 

Table 28.116: STANDBY timer information element contents 



Information element 


Length 


Value 


Remark 


STANDBY timer 


4 





Reserved 


1 


10s 


2 


30 s 


3 


1 min 


4 


5 min 


5 


10 min 


6 


30 min 


7 


1 hour 


8 


2 hours 


9 


3 hours 


10 


6 hours 


11 


12 hours 


12 


24 hours 


13 


48 hours 


14 


72 hours 


15 


Forever 



28.4.5.40 SwMI IPv6 Information 

The "SwMI IPv6 information" information element shall be encoded as defined in table 28.1 17. 

Table 28.117: SwMI IPv6 Information information element contents 



Information element 


Length 


C/O/M 


Value 


Remark 


IPv6 Networl< Prefix 


64 


M 






Prefix Valid Lifetime 


32 


M 






On-Link Flag 


1 


M 






Autonomous Address Configuration 


1 


M 





Not Supported 


1 


Supported 



£75/ 



1028 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



28.4.5.41 SwMI Mobile IPv4 Information 

The "SwMI Mobile IPv4 information" information element shall be encoded as defined in table 28. 11 8. 
Table 28.118: SwMI Mobile IPv4 Information information element contents 



Information element 


Length 


C/O/M 


Value 


Remark 


FA Care of Address 


32 


M 






Sequence Number 


16 


M 






FA Registration Lifetime 


16 


M 






Register via FA (R) 




M 





Registration via FA not required 


1 


Registration via FA required 


FA Busy (B) 




M 





Accepting Registrations 


1 


Accepting no Registrations 


Home Agent (H) 




M 





Offers no HA Services 


1 


Offers HA Services 


Foreign Agent (F) 




M 





Offers no HA Services 


1 


Offers HA Services 


IVIinimal Encapsulation (M) 




M 





Not Supported 


1 


Supported 


GRE Encapsulation (G) 




M 





Not Supported 


1 


Supported 


Van Jacobsen Compression (V) 




M 





Not Supported 


1 


Supported 



28.4.5.42 Transmit response reject cause 

The Transmit response reject cause information element shall be encoded as defined in table 28. 119. 

Table 28.119: Transmit response reject cause information element contents 



Information element 


Length 


Value 


Remark 


Transmit Response Reject Cause 


8 





Undefined 


1 


Unknown NSAPI 


2 


System resources not available 


23 


Requested minimum peak throughput not available 


25 


Requested schedule not available 


others 


Reserved 



28.4.5.43 Type identifier in accept 

The Type identifier in accept information element shall be encoded as defined in table 28.120. 

Table 28.120: Type Identifier in Accept information element contents 



Information element 


Length 


Value 


Remark 


Type identifier in accept 


3 





No address 


1 


IPv4 Static Address 


2 


IPv4 Dynamic Address 


3 to 7 


Reserved 
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28.4.5.44 Type 3 element identifier 

The Type 3 element identifier information element shall be encoded as defined in table 28.121. 

Table 28.121 : Type 3 element identifier information element contents 



Information element 


Length 


Value 


Remark 


Type 3 element identifier 


4 





DCOIVIP negotiation 


1 


Protocol configuration options 


2 


Data priority details 


3 


QoS 


others 


Reserved 



28.4.5.45 V.42bis compression request, Pg 

The ITU-T Recommendation V.42bis [27] compression request, Pq information element shall be encoded as defined in 

table 28.122. 

Table 28.122: ITU-T Recommendation V.42bis data compression 
request parameters information element contents 



Information element 


Length 


Value 


Remark 


V.42bis [27] data compression 
Request 


2 





compress neither direction 


1 


compress initiator-to-responder direction only 


2 


compress responder-to-initiator direction only 


3 


compress both directions 



28.4.5.46 V.42bis data compression parameters 

The ITU-T Recommendation V.42bis [27] data compression parameters information element shall be encoded as 
defined in table 28.123. 

Table 28.123: ITU-T Recommendation V.42bis data compression 
parameters information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


ITU-T Recommendation V.42bis [27] compression 
request 


2 


1 


M 




ITU-T Recommendation V.42bis [27] number of 
codewords 


16 


1 


M 




ITU-T Recommendation V.42bis [27] maximum 
string length 


8 


1 


M 





28.4.5.47 V.42bis maximum string length, P2 

The ITU-T Recommendation V.42bis [27] maximum string length, P2 information element shall be encoded as defined 
in table 28.124. 

Table 28.124: ITU-T Recommendation V.42bis maximum string length information element contents 



Information element 


Length 


Value 


Remark 


ITU-T Recommendation V.42bis [27] 
maximum string length, P2 


8 


0to5 


Reserved 


6 to 250 


Maximum number of characters in an 
uncompressed data string that is accepted to 
be encoded. 


251 to 255 


Reserved 
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28.4.5.48 V.42bis number of codewords, P^ 



The ITU-T Recommendation V.42bis [27] number of codewords, Pj information element shall be encoded as defined in 
table 28.125. 

Table 28.125: ITU-T Recommendation V.42bis number of codewords information element contents 



Information element 


Length 


Value 


Remark 


ITU-T Recommendation V.42bis [27] 
number of codewords, P.| 


16 


to 51 1 


Reserved 


512 to 65535 


Maximum number of codewords in the 
compressor dictionary. Suitable default 
value for TETRA packet data TBD 



28.5 Timers and constants 

28.5.1 Timers 

28.5.1.1 PDP_ACTIVATE_WAIT 

PDP_ACTIVATE_WAIT timer has a fixed value of 30 s. The timer is valid for MS SNDCP only. 

28.5.1.2 PDP_DEACTIVATE_WAIT 

PDP_DEACT1VATE_WAIT timer has a fixed value of 180 s. The timer is valid for MS SNDCP only. 

28.5.1.2a PDP_MODIFY_WAIT 

PDP_MODIFY_WAlT timer has a fixed value of 30 s. The timer is valid for MS SNDCP only. 

28.5.1.3 READY 

READY timer value is always given in SN-ACTIVATE PDP CONTEXT ACCEPT PDU. The latest received 
SN-ACTIVATE PDP CONTEXT ACCEPT PDU values shall be used. 



28.5.1.4 



STANDBY 



STANDBY timer value is always given in SN-ACTIVATE PDP CONTEXT ACCEPT PDU. The latest received 
SN-ACTIVATE PDP CONTEXT ACCEPT PDU values shall be used. 

28.5.1 .5 DATA_PRIORITY_REQUEST_WAIT 

DATA_PRIORITY_REQUEST_WAIT timer has a fixed value of 30 s. The timer is valid for MS SNDCP only. 

28.5.1.6 RESPONSE_WAIT 

RESPONSE_WAIT timer value is always given in SN-ACTIVATE PDP CONTEXT ACCEPT PDU. The latest 
received SN-ACTIVATE PDP CONTEXT ACCEPT PDU values shall be used. 

28.5.1.7 SERVICE_CHANGE 

SERVICE_CHANGE timer has a fixed value of 3 s. The timer is valid for MS SNDCP only. 

28.5.1.8 CONTEXT_READY 

CONTEXT_READY timer value obtains its value from the READY timer value or the QoS information element (if 
present) of the SN-ACTIVATE PDP CONTEXT ACCEPT and the SN-MODIFY PDP CONTEXT RESPONSE PDUs. 
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28.5.2 Constants 

RETRY_ACTIVATION has a fixed value 3 times. The constant is valid for MS SNDCP only. 
RETRY_MODIFICATION has a fixed value 3 times. The constant is valid for MS SNDCP only. 
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29 SDS-TL service and protocol 

The Short Data Service (SDS) as defined in clauses 13 and 14 consists of a pre-coded message service and a 
user-defined message service. The user-defined message service provides a bearer service for 16 bits, 32 bits, 64 bits or 
up to 2 047 bits of application-defined data. This bearer service and the underlying protocol ensure reliable delivery of 
user-defmed data over the air interface. However, in order to ensure inter-operability of different applications using 
SDS service, an additional header information is defined to support Short Data Service Transport Layer (SDS-TL) data 
transfer service. 

This clause defines a protocol layer for the SDS user defined data type 4 (this is carried within the 2 047 bits of 
application defined data). 

This additional protocol layer, hereafter called the SDS Transport Layer (SDS-TL), defines means which enhances the 
service provided by the layer 3 Short Data Service protocol to provide protocol mechanisms for end-to-end 
acknowledgement, store and forward and to ensure that applications using this service interpret the user data in the same 
way. Because of the additional header, this protocol is only for use with SDS type 4. In order to guarantee that the basic 
SDS user data type-4 service and the SDS-TL data transfer service do not disturb each other a protocol header is also 
added into the basic SDS user data type-4 service, refer to clauses 13.3 and 29.3.2.1. 

This clause specifies: 

• the services provided by the SDS-TL; 

• the functional requirements for the SDS-TL; 

• SDS-TL procedures for specific transmission and reception of SDS user-defined data messages; 

• the encoding of the Protocol Data Units (PDUs) defined by SDS-TL. 
The SDS-TL protocol provides the following services: 

• point-to-point message transfer; 

• point- to -multipoint message transfer; 

• broadcast message transfer; 

• end-to-end acknowledgement of message receipt and consumption by application; 

• support for multiple application protocols. 

The SDS-TL supports the following types of application which use the SDS bearer service: 

• standard applications which use the SDS-TL services; 

• non-standard applications which use the SDS-TL services; 

• standard applications which do not use the SDS-TL services; 

• non-standard applications which do not use the SDS-TL services. 
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29.1 Overview of SDS-TL 
29.1.1 Protocol architecture 

The SDS-TL data transfer service enhances the SDS type 4 data service and in effect replaces SDS type 4 data service 
to the user application. Figure 29.1 shows the position of the SDS-TL protocol in the MS/LS protocol stack. The present 
document does not define a base station protocol architecture or user application SAPs for SDS-TL within the SwMI or 
in a store and forward entity (service centre). 

User applications 
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TNCC-SAP 


1 




SDS-TL-SAP 






SDS-TL 






TNSS-SAP TNSDS-SAP 


CIVICE 


t 
















CC 




ss 




SDS 























Figure 29.1 : SDS-TL position in TETRA protocol stacl< 

SDS-TL adds a layer of protocol functionality to the SDS user-defined type 4 message protocol which is accessed using 
the TNSDS-UNITDATA request / indication primitives as defined in clause 13 through the TNSDS-SAP. Note that the 
pre-coded message service and type 1, 2 and 3 short data message service, also provided by the SDS protocol entity 
within CMCE, shall still be accessed from a user application using the TNSDS-STATUS and TNSDS-UNITDATA 
request / indication primitives; there is no other SDS-TL protocol functionality for these services expect that the 
SDS-TL protocol uses a range of STATUS PDUs for acknowledgement purposes. 

The present document defines in clause 29.5 standardized protocols, which use services of the TNSDS-SAP via 
SDS-TL-SAP. Those protocols shall run parallel to each other and other protocols utilizing SDS-TL without any 
interactions. 

NOTE 1: In clause 29 terminology "SDS DATA PDU" is used to indicate either U-SDS DATA or D-SDS DATA 
PDU or an information element of it as defined in clause 14. SDS-TL PDUs refer to the PDUs defined in 
clause 29 and transported inside in the User-defined data-4 information element of the SDS DATA PDU. 

NOTE 2: The term "message" is used in service descriptions when the actual PDU name is not relevant. 

NOTE 3: The external subscriber number (information element) may be present both as a part of the SDS DATA 
PDU and as a part of the SDS-TL PDU inside the forward address information element. The position of 
the external subscriber number defines its meaning and is indicated when necessary. 
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29.1.2 Addressing 



The SDS-TL layer modifies network layer addressing of the SDS, when store and forward capability is used. The 
sending entity will always indicate at the U/D-SDS DATA PDU the address of the next node. When the next node is 
a store and forward entity, then the final address will be inside the SDS-TL PDU as a forward address. When the 
sending entity is the store and forward entity then its address is as the source address in the SDS-DATA PDU and the 
real source address is in the SDS-TL PDU in the forward address information element. Refer to clause 29.3.1 for further 
details. 

In the protocol model, the external subscriber number (MS-ISDN number) of the sending user is known in the SwMI 
based on the ITSI of the subscriber and the sending MS/LS does not send it. It is also assumed that the MS/LS user 
application knows its MS-ISDN number from its ITSI and does not receive it as an additional external subscriber 
number. MS/LS may use an MS-ISDN number as a destination address in the external subscriber number information 
element either in the SDS DATA PDU or in the forward address information element and may receive it as a source 
address in the external subscriber number information element either in the SDS DATA PDU or in the forward address 
information element. 

When MS/LS uses the external subscriber number as a destination address with store and forward entity there is no 
gateway address inside the forward address information element for the external subscriber or MS-ISDN user and it is 
assumed that the SwMI or the store and forward server can route the message to a proper gateway or destination. 

NOTE: The service primitives and protocol PDUs use the same parameter and information element names, which 
may give a wrong impression of the usage of those parameters and information elements in a store and 
forward case, refer to relevant notes in the definition tables. 

29.1 .3 SDS-TL Requirement to SDS and STATUS services 

29.1 .3.1 Requirements to MS/LS 

In order to support SDS-TL data transport service the MS/LS shall support SDS type 4 data service at TNSDS-SAP as 
defined in clause 13 and transportation a range of status values, refer to clause 29.4.2.3. 

29.1.3.2 Requirements to the SwMI 

In order to support SDS-TL data transport service the SwMI shall support SDS type 4 data and status services as 
defined in clause 13. 



29.2 SDS-TL Service Descriptions 



The following service descriptions describe the SDS-TL services provided to the higher layers in the MS/LS protocol 
stack. 

29.2. 1 Services available at the SDS-TL-SAP 

The SDS-TL data transfer service shall provide the means whereby SDU are transmitted from a source to a destination 
in a reliable manner. The source can request confirmation of reception and consumption from the destination. The 
reception and consumption confirmation can also be transferred in a reliable manner. 

The reliable aspect of the transfer can either be achieved transparently through the SwMI or by utilizing store and 
forward capability of the SwMI. The implementation of the store and forward (service centre) entity is outside the scope 
of the present document. 
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29.2.2 Service primitives at tine SDS-TL-SAP 

TLSDS-TRANSFER request: the primitive shall be used by the SDS-TL entity to send data to a peer entity. 
Parameters indicate whether reporting is requested. 

TLSDS-TRANSFER indication: the primitive shall be used by the SDS-TL to pass to the SDS-TL entity data, which 
has been received from a peer entity. 

Table 29.1 gives parameters for the TLSDS-TRANSFER primitives, when no store and forward entity is used. 
Table 29.1 : Parameters for the TLSDS-TRANSFER primitive without store and forward addressing 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 





- 


Called party 


(see note 1) 


(see note 5) 


Called party SNA 


(see note 2) 


- 


Called party SSI 


M (see note 2) 


M 


Called party extension 


(see note 2) 


M 


External subscriber number (called party) 





- 


Received address type 


- 





Calling party 


- (see note 3) 


(see note 6) 


Calling party SSI 


- 


M 


Calling party extension 


- 


M 


External subscriber number (calling party) 


- 





Protocol identifier 


M 


M 


Delivery report request 


M 


M 


Service selection 


M 


- 


Short form report 


- 


M 


Storage 








Validity period 








Message reference handle 


M 


- 


Message reference 


- 


M 


Time stamp 


(see note 7) 


(see note 7) 


User data 








NOTE 1 : This parameter shall indicate the destination entity address. 

NOTE 2: This parameter shall be present as defined by the called party type identifier 

parameter. 
NOTE 3: Lower protocol layers will add the calling party identity. 
NOTE 4: Void. 
NOTE 5: This parameter value shall indicate "Called party SSI" and "Called party 

extension". 
NOTE 6: This parameter value shall indicate "Calling party SSI" and "Calling party 

extension". 
NOTE 7: Availability of this parameter is protocol dependent refer to clauses 29.3.2.9 and 

29.5.3.3. Normally the SwMI will add the timestamp to the message and the 

timestamp in the request is to support those cases where that service is not 

available in the SwMI. 
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Table 29.2 gives parameters for the TLSDS-TRANSFER primitives, when a store and forward entity is used. 

Table 29.2: Parameters for the TLSDS-TRANSFER primitive with store and forward addressing 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 





- 


Called party: 


(see note 1 ) 


(see note 7) 


Called party SNA 


C (see note 2) 


- 


Called party SSI 


C (see note 2) 


M 


Called party extension 


C (see note 2) 


M 


External subscriber number 


(see note 1) 


- 


Received address type 


- 





Calling party: 


- (see note 3) 


(see note 9) 


Calling party SSI 


- 


C (see note 8) 


Calling party extension 


- 


C (see note 8) 


External subscriber number (calling party) 


- 


(see note 9) 


Protocol identifier 


M 


M 


Delivery report request 


M 


M 


Service selection 


M 


- 


Short form report 


- 


M 


Storage 


M (see note 4) 


M (see note 4) 


IVIessage reference handle 


M 


- 


IVIessage reference 


- 


M 


Validity period 


M 





Forward address: 


(see note 5) 


(see note 1 0) 


Forward address SNA 


C (see note 6) 




Forward address SSI 


C (see note 6) 


C (see note 11) 


Forward address extension 


C (see note 6) 


C (see note 11) 


External subscriber number 


C (see note 6) 


C (see note 11) 


Time stamp 


0(see note 12) 


(see note 12) 


User data 








NOTE 1 : This parameter shall indicate the store and forward entity address to which the 

message is going for delivery to the destination. 
NOTE 2: This parameter shall be present as defined by the called party type identifier 

parameter. 
NOTE 3: Lower protocol layers will add the calling party identity. 
NOTE 4: This parameter shall indicate "storage allowed". 

NOTE 5: This information element shall indicate the final destination entity address. 
NOTE 6: This parameter shall be present as defined by the forward address type identifier 

parameter. 
NOTE 7: This parameter value shall indicate "Called party SSI" and "Called party 

extension". This identity shall indicate the destination. 
NOTE 8: This parameter shall be present as defined by the calling party type identifier 

parameter. 
NOTE 9: This parameter shall indicate the store and forward entity address to which sent 

the message on behalf of the original source. 
NOTE 10: This parameter shall indicate the original source entity address. 
NOTE 1 1 : This parameter shall be present as defined by the forward address type identifier 

parameter. 
NOTE 12: Availability of this parameter is protocol dependent refer to clauses 29.3.2.9 and 

29.5.3.3. Normally the SwMI will add the timestamp to the message and the 

timestamp in the request is to support those cases where that service is not 

available in the SwIVII. 



TLSDS-REPORT request: the primitive shall be used by the SDS-TL entity to send reports to a peer entity. 
Parameters indicate whether reporting is requested. 

TLSDS-REPORT indication: the primitive shall be used by the SDS-TL to pass to the SDS-TL entity reports, which 
has been received from a peer entity or generated by the SwMI or a service centre. 

NOTE: A TLSDS-TNSDS-REPORT indication is used to convey local LLC generated reports about the PDU 
transfer result. 
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Table 29.3 gives parameters for the TLSDS-REPORT primitives, when no store and forward entity is used. 
Table 29.3: Parameters for the TLSDS-REPORT primitive (no store and forward) 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 





- 


Called party: 


See note 1 


See note 4 


Called party SNA 


C (see note 2) 


- 


Called party SSI 


C (see note 2) 


M 


Called party extension 


C (see notes 
2 and 7) 


M 


External subscriber number (called party) 


(see note 7) 


- 


Calling party: 


See note 3 


See notes 5 and 6 


Calling party SSI 


- 


M 


Calling party extension 


- 


M 


External subscriber number (calling party) 


- 


(see notes6 and 7) 


Protocol identifier 


IVI (see note 7) 


M (see note 7) 


Acknowledgement required 


M (see note 8) 


M (see note 8) 


Delivery status 


M (see note 8) 


M (see note 8) 


IVIessage reference handle 


- 


(see note 9) 


IVlessage reference 


M 


M 


Time stamp 


(see note 1 0) 


(see note 1 0) 


User data 


(see note 7) 


(see note 7) 


NOTE 1 : This parameter shall indicate the destination entity address. 

NOTE 2: This parameter shall be present as defined by the called party type identifier 

parameter. 
NOTE 3: Lower protocol layers will add the calling party identity. 
NOTE 4: This parameter value shall indicate "Called party SSI" and "Called party extension". 

This parameter shall indicate the destination entity address. 
NOTE 5: This parameter shall value indicate "Calling party SSI" and "Calling party extension". 
NOTE 6: This parameter shall indicate the source entity address. 
NOTE 7: Not applicable for short reports. 
NOTE 8: For short reports these parameters are set to default values locally or may have a 

limited range of values. 
NOTE 9: This parameter shall be used in the first TLSDS-REPORT indication to a 

TLSDS-TRANSFER request. 
NOTE 1 0: Availability of this parameter is protocol dependent refer to clauses 29.3.2.9 and 

29.5.3.3. Normally the SwMI will add the timestamp to the message and the 

timestamp in the request is to support those cases where that service is not available 

in the SwMI. 
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Table 29.4 gives parameters for the TLSDS-REPORT primitives, when a store and forward entity is used. 
Table 29.4: Parameters for the TLSDS-REPORT primitive (store and forward) 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 





- 


Called party 


See note 1 


See note 4 


Called party SNA 


C (see note 2) 


- 


Called party SSI 


C (see note 2) 


M 


Called party extension 


C (see note 2) 


M 


External subscriber number 


(see note 1 ) 


- 


Calling party 


See note 3 


See notes 5 and 6 


Calling party SSI 


- 


M 


Calling party extension 


- 


M 


External subscriber number (calling party) 


- 


(see note 6) 


Protocol identifier 


M 


M 


Acknowledgement required 


M 


M 


Delivery status 


M 


M 


Storage 


M (see note 13) 


M (see note 13) 


IVIessage reference handle 


- 


(see note 7) 


IVIessage reference 


M 


M 


Validity period 


M 





Forward address: 


See note 8 


See note 10 


Forward address SNA 


C (see note 9) 




Forward address SSI 


C (see note 9) 


C (see note 1 1 ) 


Forward address extension 


C (see note 9) 


C (see note 1 1 ) 


External subscriber number 


C (see note 9) 


C (see note 1 1 ) 


Time stamp 


(see note 1 2) 


(see note 1 2) 


User data 








NOTE 1 : This parameter shall indicate the store and forward entity address which sent the 

reported message on behalf of the original source. 
NOTE 2: This parameter shall be present as defined by the called party type identifier 

parameter. 
NOTE 3: Lower protocol layers will add the calling party identity. 
NOTE 4: This parameter value shall indicate "Called party SSI" and "Called party extension". 

This identity shall indicate the destination. 
NOTE 5: This parameter value shall indicate "Calling party SSI" and "Calling party extension". 
NOTE 6: This parameter shall indicate the store and forward entity address to which the 

reported message was originally sent. 
NOTE 7: This parameter shall be used in the first TLSDS-REPORT indication to 

a TLSDS-TRANSFER request. 
NOTE 8: This information element shall indicate the final destination entity address. 
NOTE 9: This parameter shall be present as defined by the forward address type identifier 

parameter. 
NOTE 10: This parameter shall indicate the original source entity address. 
NOTE 1 1 : This parameter shall be present as defined by the forward address type identifier 

parameter. 
NOTE 12: Availability of this parameter is protocol dependent refer to clauses 29.3.2.9 and 

29.5.3.3. Normally the SwMI will add the timestamp to the message and the 

timestamp in the request is to support those cases where that service is not available 

in the SwIVII. 
NOTE 13: This parameter shall indicate "storage allowed". 



TLSDS-ACK request: the primitive shall be used by the SDS-TL entity to acknowledge reports from a peer entity. The 
TLSDS-ACK request is used to acknowledge unsolicited reports (consumed message) or reports which may have been 
stored in the SwMI or at a service centre. 

TLSDS- ACK indication: the primitive shall be used by the SDS-TL to pass to the SDS-TL entity report 
acknowledgements, which has been received from a peer entity or generated by the SwMI or a service centre. 
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Table 29.5 gives parameters for the TLSDS-ACK primitives, when no store and forward entity is used. 
Table 29.5: Parameters for the TLSDS-ACK primitive (no store and forward) 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 





- 


Called party 


See note 1 


See note 4 


Called party SNA 


C (see note 2) 


- 


Called party SSI 


C (see note 2) 


M 


Called party extension 


C (see note 2) 


M 


External subscriber number (called party) 





- 


Calling party 


See note 3 


See notes 5 and 6 


Calling party SSI 


- 


M 


Calling party extension 


- 


M 


External subscriber number (calling party) 


- 


(see note 6) 


Protocol identifier 


M 


M 


Delivery status 


M 


M 


Message reference 


M 


M 


NOTE 1 : This parameter shall indicate the destination entity address. 

NOTE 2: This parameter shall be present as defined by the called party type identifier 

parameter. 
NOTE 3: Lower protocol layers will add the calling party identity. 
NOTE 4: This parameter value shall indicate "Called party SSI" and "Called party 

extension". This parameter shall indicate the destination entity address. 
NOTE 5: This parameter value shall indicate "Calling party SSI" and "Calling party 

extension". 
NOTE 6: This parameter shall indicate the source entity address. 



Table 29.6 gives parameters for the TLSDS-ACK primitives, when a store and forward entity is used. 
Table 29.6: Parameters for the TLSDS-ACK primitive (store and forward) 



Parameter 


Request 


Indication 


Access priority 





- 


Traffic stealing 





- 


Area selection 





- 


Called party: 


See note 1 


See note 4 


Called party SNA 


C (see note 2) 


- 


Called party SSI 


C (see note 2) 


M 


Called party extension 


C (see note 2) 


M 


External subscriber number 


(see note 1 ) 


- 


Calling party: 


See note 3 


See notes 5 and 6 


Calling party SSI 


- 


M 


Calling party extension 


- 


M 


External subscriber number (calling party) 


- 


(see note 6) 


Protocol identifier 


M 


M 


Delivery status 


M 


M 


Message reference 


M 


M 


NOTE 1 : This parameter shall indicate the store and forward entity address from which the 

acknowledged report message was received. 
NOTE 2: This parameter shall be present as defined by the called party type identifier parameter. 
NOTE 3: Lower protocol layers will add the calling party identity. 
NOTE 4: This parameter value shall indicate "Called party SSI" and "Called party extension". This 

identity shall indicate the destination. 
NOTE 5: This parameter value shall indicate "Calling party SSI" and "Calling party extension". 
NOTE 6: This parameter shall indicate the store and forward entity address to which the 

acknowledged report message was originally sent. 
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TLSDS-TNSDS-REPORT indication: the primitive shall be used to indicate whether a TLSDS-ACK request, a 
TLSDS-TRANSFER request, a TLSDS-REPORT request, or a TLSDS-UNITDATA request has been either transmitted 
successfully or the transmission failure reason (the result of the TNSDS-REPORT). Refer to clause 13.3.2.2 for 
primitive contents. 

TLSDS-UNITDATA request: the primitive shall be used to send user defined data-4 to a peer entity, when not using 
the SDS-TL data transfer services. Refer to clause 13.3.2.2 for primitive contents. The user defined data-4 parameter 
shall contain the protocol identifier parameter and the actual user data. 

TLSDS-UNITDATA indication: the primitive shall be used to receive user defined data-4 from a peer entity, when not 
using the SDS-TL data transfer services. Refer to clause 13.3.2.2 for primitive contents. The user defined data-4 
parameter shall contain the protocol identifier parameter and the actual user data. 

29.2.3 SDS-TL primitives' parameters 

Parameter values shall be as defined in this clause and in clause 13.3.3 for the basic SOS. 
Acknowledgement required = 

• no further acknowledgements required for this message; or 

• acknowledgement required for this message. 
Delivery report request = 

• no delivery report requested; 

• message received report requested; 

• message consumed report requested; or 

• message received and consumed report requested. 
Delivery status = 

• Refer to clause 29.4.3.2 for further details. 
Forward address = 

• SNA; 

• SSI; 

• SSI and address extension; or 

• external subscriber number. 
Message reference = 

• to 255. 
Message reference handle = 

• to 255, a local handle to the actual message reference. The mapping between a message reference and a 
message reference handle is a local issue and outside the scope of the present document. 

Protocol identifier = 

• Protocol which is invoked by the primitive, refer to clause 29.4.3.9. 
Service selection = 

• individual service; or 

• group or individual service. 
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Short form report = 

• Use of short form report is recommended (during the vaHdity period of the message); 

• Only standard report allowed. 
Storage = 

• storage not allowed; or 

• storage allowed. 
Validity period = 

• one try, no extended validity period; 

• 10 s to 2 weeks; or 

• network determined. 



29.2.4 State description 



IDLE 




TLSDS-TRANSFER request 
TLSDS-TRANSFER indication 
TLSDS-REPORT request 
TLSDS-REPORT indication 
TLSDS-ACK request 
TLSDS-ACK indication 
TLSDS-TNSDS-REPORT indication 
TLSDS-UNITDATA request 
TLSDS-UNITDATA indication 



Figure 29.2: State transition diagram 



The IDLE state represents the initial and final state of all the primitive sequences as defined in figure 29.2. Note that 
this state transition diagram represents the state transfer of the SDS-TL entity, not the application using SDS-TL. The 
state diagram of such applications is outside the scope of the present document. 

29.3 Protocol description 
29.3.1 Addressing meciianism 

When sending an SDS-TL message, the addressing to the final destination is achieved in a number of different ways 
depending whether a store and forward function is used or not. Following destination addresses are specified in an 
SDS-TL message from MS/LS to SwMI: 

• Called party address (destination or next node) in U-SDS-DATA PDU part; 

• External subscriber number (destination or next node) in U-SDS-DATA PDU part; 
NOTE 1 : The previous addresses can be used for all of the SDS-TL PDUs. 

• Forward address (destination) in SDS-TRANSFER PDU part; 

• Forward address (original source) in the SDS-REPORT PDU; and 

• The used MAC layer address implies the source address. 
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Following source addresses are specified in an SDS-TL message from SwMI to MS/LS: 

• Calling party address (source or previous node) in D-SDS-DATA PDU part; 

• External subscriber number (source or previous node) in D-SDS-DATA PDU part; 
NOTE 2: The previous addresses can be used for all of the SDS-TL PDUs. 

• Forward address (source) in SDS-TRANSFER PDU part; 

• Forward address (original destination) in the SDS-REPORT PDU; and 

• The used MAC layer address implies the destination address. 

The called party address is always present and always indicates the next node address (final destination, store and 
forward entity or gateway and external subscriber number). 

The external subscriber number is an optional information element that allows sending of up to 24 digits in 
e.g. an ISDN address. When used in the U-SDS-DATA PDU it amends the called party address (PDU next destination). 
When used in the D-SDS-DATA PDU is amends the calling party address (PDU latest source). When used in the 
forward address it is the final destination or original source address. 

The forward address is an optional information element that indicates the final destination or original source TETRA 
address. It may be an SSI, SSI and address extension (TSI) or external subscriber number. 

The calling party address is always present and always indicates the previous node address (final destination, store and 
forward entity or gateway and external subscriber number). In case no forward address is used, the called party address 
(optionally amended by the external subscriber number) indicates the final destination and the calling party address 
(optionally amended by the external subscriber number) indicates the source. The use of the addresses in this case is 
shown in table 29.7. The addressing of having the final destination / original source in external subscriber number 
information element of the U-SDS DATA PDU and gateway address in the called party address information element is 
supported by this addressing scenario. 

In case the forward address is used, this address indicates the true destination or original source, and the called or 
calling party address in the SDS-DATA PDU (optionally amended by the external subscriber number in U-SDS DATA 
or D-SDS DATA PDU) indicates the next or previous node address. The use of the addresses in this case for MS to MS 
communication is shown in table 29.8. 

The use of the addresses in the case of communication via a gateway to a user addressed by the external subscriber 
number is shown in table 29.9. In that table, user 2 is addressed by the external subscriber number in the forward 
address field or in the U-SDS-DATA. A target MS (using an MS-ISDN) may be addressed using any of the following 
combinations: 

• via a gateway by indicating the gateway SSI in the called party address and the target in the external subscriber 
number of the U-SDS-DATA with no forward address (the SSI is the gateway address); or 

• via a gateway by indicating the gateway SSI in the called party address and an external subscriber number in 
U-SDS-DATA (in which case the external subscriber number identifies some gateway), with the final target in 
the external subscriber number of the forward address field. 

The SwMI may control usage of the forward address by the SYSINFO broadcast, refer to clause 21.4.4.1 table 21.67. 
The SDS-TL addressing method information element values has the meaning: 

• "Service centre addressing preferred" defines that the MS shall address the SDS-TL transport service PDUs so 
it contains the destination of the PDU in the forward address information element and the service centre 
address in the called party or in the called party and external subscriber number information element of the 
SDS DATA PDU. Exceptions to that rule are: 

MS doesn't know the store and forward entity (service centre) address in which case MS may attempt to 
send the PDU without the forward address directly to the destination. In this scenario, the SwMI may 
either support the addressing types as defined by "Never use service centre addressing" or the SwMI may 
reject the message; 

NOTE 3: The SwMI may support SDS-TL transport services and use a default store and forward entity or may not 
support SDS-TL transport services but behave as a transparent SwMI. 



ETSI 



1043 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



MS is sending the message to a user of another SwMI in which case it may or may not use a forward 
address. How MS knows whether the other SwMI supports forwards addressing and how it knows the 
store and forward address of the other SwMI and the behaviour of the other SwMI are outside the scope 
of the present document. 

• "Never use service centre addressing" defines that the MS shall address the SDS-TL transport service PDUs 
directly to the destination of the PDU. The message should be addressed directly to the destination, and the 
forward address shall not be used. If storage is required (a SwMI may support storage without requiring a 
service centre to be addressed), the storage bit shall set to "storage allowed" and the forward address type shall 
be set to "no forward address present". Otherwise, the storage bit shall be set to "storage not allowed". 
Exception to the forward addressing rule is: 

MS is sending the message to a user of another SwMI in which case it may or may not use a forward 
address. How MS knows whether the other SwMI supports forwards addressing and how it knows the 
store and forward address of the other SwMI and the behaviour of the other SwMI are outside the scope 
of the present document. 

NOTE 4: The broadcast value "never use service centre addressing" normally indicates that the SwMI does not 
support store and forward functionality. 

"MS choice to use service centre addressing" defines that the MS may select the addressing it applies. 
The SwMI supports both addressing with and without a service centre. MS should use PDUs without 
a forward address when it is not using the transport services (store and forward) of the SwMI. 

The SYSINFO broadcast information shall control the addressing of the SDS-TRANSFER PDU. The addressing of the 
SDS-REPORT PDU shall be the same as used in the corresponding SDS-TRANSFER PDU and the SDS-REPORT 
PDU should use the same store and forward entity (service centre) as used in the original received SDS-REPORT PDU 
so that also the store and forward entity can update its reporting status information. 

Table 29.7: MSI to MS2 transparent 



PDU and hop 


Source 
address in 

the SDS 
DATA PDU 


Destination 

address in 

the SDS 

DATA PDU 


Forward 
address 


Remark 


SDS-TRANSFER MS1 ^ MS2 


MS1 


MS2 


- 


No forward address 


SDS-REPORT MS2 ^ MS1 

(received) 


MS2 


MS1 


- 


No forward address 


SDS-REPORT MS2 ^ MS1 
(consumed) 


MS2 


MS1 


- 


No forward address 


SDS-ACK MS1 ^ MS2 
(consumed-ack) 


MS1 


MS2 


N/A 




NOTE: The destination address can be any addressing type of the SDS-DATA PDU. 
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Table 29.8: MS1 to MS2 using forward address 



PDU and hop 


Source 
address in 

the SDS 
DATA PDU 


Destination 

address in 

the SDS 

DATA PDU 


Forward 
address 


Remark 


SDS-TRANSFER MSI ^ SwMI 


MSI 


SwMI 


MS2, 
(see note 1 ) 


Forward address indicates the 
true destination 


SDS-REPORTSwMI ^ MS1 
(delivered /stored) 


SwMI 


MSI 


MS2, 
(see note 3) 


If present forward address 
indicates the destination of the 
original SDS-TRANSFER 
PDU 


SDS-TRANSFER SwMI ^ MS2 


SwMI 


MS2 


MSI 


Forward address indicates the 
true source 


SDS-REPORT MS2 ^ SwMI 
(received) 


MS2 


SwMI 


MS1, 
(see note 2) 


Forward address indicates the 
original source of the reported 
SDS-TRANSFER PDU 


SDS-REPORT SwMI ^ MSI 
(received) 


SwMI 


MSI 


MS2, 
(see note 3) 


If present forward address 
indicates the destination of the 
original SDS-TRANSFER 
PDU 


SDS-ACK MSI ^ SwMI 
(received-acl<) 


MSI 


SwMI 


N/A 




SDS-REPORT MS2 ^ SwMI 
(consumed) 


MS2 


SwMI 


MS1, 
(see note 2) 


Forward address indicates the 
original source of the reported 
SDS-TRANSFER PDU 


SDS-ACK SwMI -» MS2 
(consumed-ack) 


SwMI 


MS2 


N/A 




SDS-REPORT SwMI ^ MS1 
(consumed) 


SwMI 


MSI 


MS2, 
(see note 3) 


If present forward address 
indicates the destination of the 
original SDS-TRANSFER 
PDU 


SDS-ACK MSI -^ SwMI 
(consumed-ack) 


MSI 


SwMI 


N/A 




NOTE 1 : The use of the Forward address is controlled by the SYSINFO broadcast, refer to clauses 21 .4.4.1 

tables 21 .33 and 29.3.1. 
NOTE 2: The forward address is used because the original SDS-TRANSFER PDU to MS2 contained a forward 

address. 
NOTE 3: The forward address is optional. 
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Table 29.9: MS1 to MS2/user 2 using forward address via a gateway 



PDU and hop 


Source 
address in 

the SDS 
DATA PDU 


Destination 

address in 

the SDS 

DATA PDU 


Forward 
address 


Remark 


SDS-TRANSFER MSI ^ SwIVII 


MSI 


SwMI /SwMI 
with User 2 in 

external 
subscriber 

number 


user 2 / N/A, 
(see note 1 ) 


Forward address may indicate 
the true destination or the true 
destination may be in the 
external subscriber number 
field 


SDS-REPORT SwMI -^ MS1 
(delivered / stored) 


SwMI 


MSI 


MS2, 
(see note 3) 


If present forward address 
indicates the destination of the 
original SDS-TRANSFER 
PDU 


SDS-TRANSFER SwMI ^ 
MS2/user 2 


SwMI 


MS2/user 2 


MSI 


Forward address indicates the 
true source 


SDS-REPORT MS2/user 2 ^ SwMI 
(received) 


MS2/user 2 


SwMI 


MSI, 
(see note 2) 


Forward address indicates the 
source of the reported 
SDS-TRANSFER PDU 


SDS-REPORT SwMI ^ MS1 
(received) 


SwMI 


MSI 


MS2/user 2, 
(see note 3) 


If present forward address 
indicates the destination of the 
original SDS-TRANSFER 
PDU 


SDS-ACK MSI ^ SwMI 
(received-acl<) 


MSI 


SwMI 


N/A 




SDS-REPORT MS2/user 2 -» SwMI 
(consumed) 


MS2/user 2 


SwMI 


MSI, 
(see note 2) 


Forward address indicates the 
source of the reported 
SDS-TRANSFER PDU 


SDS-ACK SwMI ^ MS2/user 2 
(consumed-ack) 


SwMI 


MS2/user 2 


N/A 




SDS-REPORT SwMI ^ MS1 
(consumed) 


SwMI 


MSI 


MS2/user 2, 
(see note 3) 


If present forward address 
indicates the destination of the 
original SDS-TRANSFER 
PDU 


SDS-ACK MSI ^ SwMI 
(consumed-ack) 


MSI 


SwMI 


N/A 




NOTE 1 : The use of the Forward address is controlled by the SYSINFO broadcast, refer to clauses 21 .4.4.1 

table 21.67. 
NOTE 2: The forward address is used because the original SDS-TRANSFER PDU to MS2/user 2 gateway 

contained a forward address. In the case of a TETRA gateway, the PDU exchange is internal to SwMI and 

may not be explicit. 
NOTE 3: The forward address is optional. 



"MSI", "MS2", and "SwMI" here denotes the address of the originating and destination MS, and the address of the store 
and forward point. The "SwMI" address may comprise a gateway address or a gateway address and an external 
subscriber address. 

29.3.2 Description of protocol elements 

The clauses 29.3.2.1 to 29.3.2.10 describe the key aspects of the SDS-TL protocol information elements. 



29.3.2.1 



Protocol identifier 



Each SDS-DATA type 4 PDU which is sent shall contain a protocol identifier. The protocol identifier shall indicate to 
the addressed entity application which type of application protocol is using the SDS service. The present document 
currently defines a number of protocol identifiers to provide e.g. OTAK, text messaging, location system, WAP, 
WCMP, end-to-end encrypted message, immediate text messaging, M-DMO, PIN-authentication, LIP and message with 
user data header application services. A number of reserved protocol identifiers allow additional standard data services 
to be added in the future. There is also a range of protocol identifiers available for user definition. The value of the 
protocol identifier determines whether the SDS-TL (data transfer service) protocol elements and the protocol defined in 
the present document shall be used (see table 29.21). 
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29.3.2.2 End-to-end acknowledgement types 

The main objective of the SDS-TL protocol, as well as providing a mechanism to indicate the type of application using 
the service, is to provide a means for end-to-end acknowledgement of messages; this mechanism is not provided by the 
TETRA SDS service as defined in clause 14. SDS-TL provides two types of end-to-end acknowledgement which are 
distinct from the layer 2 acknowledgement procedures already provided by the LLC. The type of end-to-end 
acknowledgement which shall apply to a message transfer is set by the originator using the "Delivery report request" 
information element. These end-to-end acknowledgement types are described below. 

• Layer 2 acknowledgement only i.e. no end-to-end acknowledgement. 

• The LLC provides an acknowledged service for PDUs transferred point-to-point over a single hop i.e. MS to 
SwMI or SwMI to MS. This acknowledgement confirms to the sender that the layer 3 PDU was received 
correctly by the receiver. However, the LLC acknowledgement does not imply that the receiving end has yet 
examined the contents of the PDU. Figure 29.3 illustrates the layer 2 acknowledgement. 



MS SwjUjI 

U-SDS UNITDATA 



MS 



(SDS-TRANSFER) 
BL-ACK 



D-SDS UNITDATA 



(SDS-TRANSFER) 
BL-ACK 



Figure 29.3: Layer 2 Acknowledgement 



Message received: 



The "message received" acknowledgement is sent using the SDS-TL layer to indicate that a message sent 
by an MS / LS has been successfully received by the destination. This acknowledgement message is an 
SDS-TL PDU which is generated by the MS / LS after it has decoded the SDS-TL PDU received from 
the originator. (This is in contrast to a layer 2 acknowledgement which is sent before the incoming PDU 
has been decoded.) Therefore, this acknowledgement is sent by the destination back to the originator and 
simply relayed by the SwMI. This type of acknowledgement may be used for point-to-point and 
point-to-multipoint transfer although care should be used for point- to -multipoint transfer where large 
group sizes may result in a large amounts of air interface traffic for acknowledgements. Figure 29.4 
illustrates the "message received" end-to-end acknowledgement. 



MS 



SwMI 



U-SDS UNITDATA 



(SDS-TRANSFER) 
BL-ACK 



D-SDS UNITDATA 



(SDS-REPORT) 
("Message Received" 

BL-ACK 



MS 



D-SDS UNITDATA 



(SDS-TRANSFER) 
BL-ACK 



U-SDS UNITDATA 



(SDS-REPORT) 
("Message Received") 

BL-ACK 



Figure 29.4: "IVIessage received" end-to-end aci^nowledgement 
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Message consumed: 

The "message consumed" acknowledgement is sent using the SDS-TL layer to indicate that a message 
sent by an MS / LS has been consumed by the destination. Message consumption occurs after the 
SDS-TL PDU has been received and decoded by the destination application and refers to the point where 
the message is actually used by the application. Message consumption is application dependent and is 
specified in clause 29.3.2.2 for each of the standard applications covered by the present document. Once 
an application has consumed a message, it may use the SDS-TL protocol to convey this back to the 
originator. Figure 29.5 illustrates the "message consumed" end-to-end acknowledgement. Note that this 
figure does not show any "message received" acknowledgement which may be sent in between the 
message transfer and the "message consumed" acknowledgement. 



MS 



SwMI 



U-SDS UNITDATA 



(SDS-TRANSFER) 
BL-ACK 



D-SDS UNITDATA 



(SDS-REPORT) 
("Messaae Consumed") 

BL-ACK 



MS 



D-SDS UNITDATA 



(SDS-TRANSFER) 
BL-ACK 



U-SDS UNITDATA 



(SDS-REPORT) 
("Messaae Consumed") 

BL-ACK 



Figure 29.5: "Message consumed" end-to-end acknowledgement 

For the acknowledgement types "message received" and "message consumed", the SDS-TL protocol shall allow the 
originator of a message to specify which type of acknowledgement is desired from the destination. An application shall 
then make this choice depending on the type of data being delivered and whether the transfer is point-to-point or 
multipoint. SDS-TL simply provides an application with a standardized mechanism to convey these acknowledgement 
reports. 

The criteria of message consumption depends on the application. Message consumption criteria for each of the 
applications covered by the present document is defined below. 

• Text Messaging: 

Message consumption for the text messaging application shall be when the appUcation displays the text 
message to the user. Usually, this requires an action by the user to read the message which has been 
received and stored in the MS / LS. 

• Location system: 

The location system protocol does not have a clear concept of message consumption. Whether message 
consumption is applicable or not depends on the application using the protocol. 

• Simple Text Messaging: 

The simple text messaging protocol does not use the SDS-TL data transfer protocol. This means that no 
end-to-end acknowledgement is available in simple text messaging. 

• Simple location system: 

The simple location system protocol does not use the SDS-TL data transfer protocol. This means that no 
end-to-end acknowledgement is available in simple location systems. 
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Other standardized protocols using SDS: 



The other standardized protocols using SDS may or may not use the SDS-TL data transfer protocol. 
Other SDS-TL protocols may be standardized in the future and the meaning of message consumption 
defined in the present document. Alternatively, user applications may use SDS-TL where the meaning of 
message consumption is specific to that application. 

29.3.2.3 Service selection/short form report 

Each uplink SDS-TRANSFER PDU that is sent shall contain a service selection information element. The service 
selection information element is used to indicate whether the message is allowed to be sent to a group address or not. 
This is useful in a text messaging application where the user may be allowed to enter the destination address manually. 
In this case, the sending MS has no way of informing the user that this message will be sent to multiple targets. This 
could lead to substantial resource waste if, by accident, a message with non-zero delivery report requests is sent to a 
large group of MSs. 

To prevent this, the service selection information element forces the originating user to make an explicit choice that the 
message is allowed to be sent to a group. The network is then able to reject messages addressed to a group, but with the 
service selection information element set to "Individual service". 

The short form report information element on downlink SDS-TRANFER PDUs inform the destination user whether it 
should use or is not allowed to use short form reporting mechanism. 

29.3.2.4 Storage 

Each SDS-TRANSFER PDU that is sent shall contain a "storage" information element. The "storage" information 
element is used to indicate whether the SwMI is allowed to store the message longer than needed for ordinary 
processing. If indicated by this information element, the SwMI or a store and forward service point, may store the 
message for later delivery attempts if the destination is not available. 

The criterion for attempting to deliver the message again is outside the scope of the present document. 

29.3.2.5 Message reference 

Each SDS-TL data transfer service PDU that is sent shall contain a message reference information element. This 
message reference shall be used in the end-to-end acknowledgement back from the destination, or in reports from the 
SwMI or store and forward entity, to indicate to the originator which message is being acknowledged. The message 
reference shall also be used in negative acknowledgements. 

The originator should choose a different message reference for each new message sent regardless of the destination, if it 
requests a report. If an acknowledgement is outstanding, regardless of the destination, the corresponding message 
reference should not be re-used. In the source entity, the validity of the message reference of a message after an 
extended time after sending the message and expiry of the selected validity period, if any, but without receiving 
requested reports is outside the scope of the present document. 

By following this use of the message reference, the combination of the message reference, and source address (ITSI) 
shall uniquely identify each message being transported by a TETRA network. 

The store and forward entity or SwMI shall not modify the value of the message reference. 

NOTE 1 : SwMI may not include the forward address into all reports notably error reports in which case the store 
and forward entity (service centre) address may be the only destination related address in the report. 
Consequently, the message reference with the store and forward entity address is the only linkage to the 
sent message and SDS-TRANSFER PDU source entity should choose to use different message reference 
for each message independently of the destination address. 

NOTE 2: In the case of a gateway to another telecommunication network the source or destination address as 
appropriate is the TETRA address of that gateway. 

In the case of short report the message reference may be the only valid identifier of the acknowledgement. 
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29.3.2.6 Validity period 



If storage of the message is allowed, each SDS-TRANSFER or SDS-REPORT PDU which is sent by an MS / LS shall 
contain a "validity period" information element. This information element indicates how long the message should be 
held by the SwMI in the event that the message cannot be delivered to the destination. A destination MS may be 
unavailable due to being out of coverage or switched off. If the SwMI holds a message, it should attempt to deliver the 
message until the validity period expires after which the message is discarded and an error report may be sent back to 
the originating MS / LS. 

Note that the SwMI may not support a storage mechanism or it may limit the duration of the validity period in which 
case it should return an error report indicating either that the message has not been delivered and that the SwMI will not 
store the message or that the validity period has terminated. 

If the validity period is set to "0" or the element is missing then the SwMI should not store the message for an extended 
period, if it cannot be delivered. 

29.3.2.7 Forward address 

If storage is allowed, each SDS-TRANSFER which is sent by an MS / LS may contain a "forward address" information 
element. The MS uses "forward address" information element when the layer 3 destination address points to a network 
service point (e.g., a service centre) instead of the final destination. The use of such a network service point can be 
many. The network service point can: 

• identify the storing point for a message in a store and forward service; 

• identify some other value adding network device. 

The "forward address" is somewhat similar to the layer 3 information element "external subscriber number" but is 
totally independent of it. 

When used in the context of providing an addressed storing point for text messages, the forward address is used on the 
uplink is to inform the network service point of the true destination, and used on the downlink is to inform the 
destination of the true source. If no forward address is present, the true source and destination are the addresses present 
in the CMCE SDS PDU information elements except in certain error cases, refer to clause 29.3.3. 

29.3.2.8 Data coding scheme 

The data coding scheme information element shall indicate to the destination application which type of data coding is 
being used by the application according to the type of protocol identifier. For example, the text messaging application 
may use a 7-bit character coding alphabet or a 16-bit alphabet depending on the needs of the particular application. The 
text coding scheme defines some standard alphabets with some reserved values available for user definition and future 
standard coding schemes. The location system coding scheme does the same for location information. 

This information element is present in protocols where data coding scheme is of importance. The information element is 
thus not part of the layer 4 SDS-TL protocol, but rather a layer 6 addition for specific protocol identifiers (see 
table 29.21 and clause 29.5). 

29.3.2.9 Time stamp 

The time stamp information element shall indicate the approximate creation time of the message. The information 
element is added to a message by the SwMI to allow the destination to evaluate the age of the message. The SwMI 
decides whether to add the time stamp or not. How this decision is made is outside the scope of the present document, 
but can e.g. be based on the capabilities of the SwMI or on provisioning arrangements. 

In some situations the addition of the time stamp can cause the maximum allowed message length to be exceeded. The 
SwMI should not add the time stamp in these circumstances, regardless of provisioning arrangements or other aspects. 

NOTE: The time stamps added by the SwMI(s) are not guaranteed to be monotonically increasing. 

This information element is present in protocols where store and forward is used and where time stamping is of 
importance. The information element is thus not part of the layer 4 SDS-TL protocol, but rather a layer 6 addition for 
specific protocol identifiers (see table 29.21 and clause 29.5). 
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29.3.2.1 User data length 



The length of the "User data" information element (the payload) is derived from the length field in the SDS DATA PDU 
header. This field indicates the number of bits in the SDS payload, including the (known) length of the SDS-TL header. 

For applications, such as simple text messaging, the number of bits in the "User data" information element together with 
the "Text coding scheme" information element can then be used to derive the number of characters in a message. For 
example, if the layer 3 SDS type 4 header specifies a length of 86 bits and the coding scheme is 7-bit ASCII, then the 
"User data" information element contains 70 bits of characters of 7 bits after removal of the SDS-TL header (protocol 
identifier and text coding scheme), indicating that there are 10 characters present. 

29.3.3 Procedures 
29.3.3.1 General description 

Figure 29.6 shows the protocol sequence for a message transfer from an MS to a destination MS (or group of MSs), 
where both the received and consumed end-to-end acknowledgements are requested. The SDS-TRANSFER is carried 
by U/D-SDS-DATA PDUs with an end-to-end acknowledgement being sent by the application of the destination MS on 
receipt of the message. The acknowledgement is conveyed using SDS-REPORT which is also carried by 
U/D-SDS-DATA PDUs. On consumption of the message by the application e.g. the user reading a text message, a 
second end-to-end acknowledgement (SDS-REPORT PDU) is sent by the destination back to the originating MS. This 
second acknowledge can almost be considered a second service invocation: the linkage to the original transfer is the 
message reference and the addresses of the MSs, refer to table 29.7. Because of this, application may request the 
SDS-REPORT PDU be end-to-end acknowledged as well. This acknowledgement shall be conveyed using SDS-ACK 
PDU. Note that if the destination consumes the message before the message received report is sent the destination may 
only send back the consumed report. 

If the end-to-end mechanisms are used, the application should define procedures for handling of retries in case of 
missing acknowledgements. These procedures are application specific and outside the scope of the present document 

The protocol is here used transparently to the SwMI, which only acts as a layer 3 network. This means that part of this 
protocol sequence can be left out by the application: the SwMI need not to be aware of this. In particular, the SDS-TL 
protocol allows the application to specify which kind of acknowledgement is requested by the message source. If 
storage is not allowed, the SwMI should always act transparently. 
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NOTE: The tlsds_tnsds report (message successfully transferred to SwMI) as the first response to the tIsds 
transfer req is an example of lower layer reports (BL-ACK PDU) and is not repeated for all requests. 

Figure 29.6: SDS message transfer with end-to-end acltnowledgement, SwIVII transparent 

If the SwMI stores the message for later delivery, the SwMI store and forward entity may inform the originating MS by 
sending an SDS-REPORT PDU. This is shown in figure 29.7. This informs the originating MS that the message has 
been received by the store and forward service: note that this message should be sent if either the "message received" or 
"message consumed" delivery reports are requested. On consumption of the message by the application e.g. the user 
reading a text message, a second end-to-end acknowledgement is sent by the destination back to the originating MS, 
again through the store and forward service. 

NOTE 1: In figures 29.6 to 29.8 texts in brackets next to service primitives indicate a completion of an action not 
a service primitive parameter value. 

Note that the protocol sequence changes when the SwMI does store and forward. First, the sequence of messages 
changes because of the "intelligent" part resident in the SwMI. Secondly, one additional layer 4 acknowledgement may 
be needed: the "message received" acknowledge back to source shall, if requested, be acknowledged. However, even if 
store and forward is supported in the SwMI and allowed by the message source, the protocol sequence can be the same 
as in the transparent case: if the SwMI delivers the message immediately, the "message stored by SwMI" may not be 
sent. Note that the SwMI now plays an active role, and leaving out part of this protocol sequence do require that the 
SwMI is aware of it. 

If the "forward address" information element is used to provide store and forward service via and addressed network 
service point, the true destination address is only visible inside the initial SDS-TRANSFER PDU on the source (left) 
side of the SwMI (see figure 29.7). The same applies for the true source address on the destination (right) side. Seen 
from the SwMI perspective, the source and the destination will no longer communicate with each other, but both will 
communicate with the store and forward entity. 

When using store and forward the SwMI store and forward entity may choose to modify the SDS-REPORT PDU to the 
source to get an additional SDS-ACK as show in figure 29.7. 
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NOTE: The tlsds_tnsds report (message successfully transferred to SwMI) as the first response to the tIsds 
transfer req is an example of lower layer reports (BL-ACK PDU) and is not repeated for all requests. 

Figure 29.7: SDS message transfer with end-to-end acltnowledgement, SwIVII does store and forward 

When using store and forward and requesting "message consumed" report but not "message received", the SwMI may 
choose to modify the SDS-TRANSFER PDU to the destination, as shown in figure 29.8. This will enable the SwMI to 
stop trying to deliver the message once it has reached the destination application. 

NOTE 2: The SDS-ACK PDU is not an end-to-end acknowledge, but an acknowledge from the next node. This 
next node may or may not be the final destination. 
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NOTE: The tIsds tnsds report (message successfully transferred to SwMI) as the first response to the tIsds 
transfer req is an example of lower layer reports (BL-ACK PDU) and is not repeated for all requests. 

Figure 29.8: SDS message transfer with consumed acltnowledge, SwIVII modifies requested reports 

29.3.3.2 MS sending a message 

An MS sends a message using SDS-TRANSFER PDU which is conveyed to the SwMI in U-SDS-DATA PDU and to 
another MS using D-SDS-DATA PDU. SDS procedures for sending U-SDS-DATA PDU and D-SDS-DATA PDU are 
described in clause 14. The SDS-TRANSFER PDU uses user-defined data type 4 which allows up to 2 047 bits of user 
data to be transferred (including SDS-TL headers). 

SDS-TRANSFER PDU shall contain the information elements defined in clause 29.4.2.4, table 29.14. 

The protocol identifier indicates the user application protocol that is using the short data transfer service. 

The message reference shall be set by the SDS-TL entity of the sending party (original source) to identify reports sent 
back from the destination or next node. The sending user application shall use a local message reference handle in the 
TLSDS -TRANSFER request primitive and the SDS-TL entity shall allocate the actual message reference and shall 
inform it the user application in the first report. The sending MS SDS-TL entity shall select a new value to the message 
reference each time it sends a new message in the SDS-TRANSFER PDU whether to the same destination or to a 
different destination. The sending MS/LS shall not select a message reference value used in a received 
SDS-TRANSFER PDU from the same source to which MS/LS is sending a SDS-TRANSFER PDU as long as there is 
a pending report request to the received SDS-TRANSFER PDU. The combination of the identities of the source address 
and the message reference shall uniquely identify the sent message. 

The short form report does not contain the Protocol identifier information element, and therefore SDS-TL entity shall 
not allocate the same message reference value for multiple applications in the same originating MS/LS when there is 
a pending report on that message reference value. The usage of the SDS-SHORT REPORT PDU is application 
independent. 

The delivery report request indicates to the SwMI and the destination for the short message the type of reports which 
are required. These may be an acknowledgement from the destination when it receives the message or an 
acknowledgement from the destination when the message is consumed or both. For a text messaging application, 
message consumption would correspond to the user reading the received text message. 
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If message storage is allowed the validity period shall inform the SwMI how long the message is valid. The SwMI may 
use this information to store the message in the situation where the destination is not available. If the message cannot be 
delivered before the validity period expires, the SwMI shall discard the message and may report back to the sending MS 
that the message delivery was unsuccessful. The SwMI may modify the validity period for its own purposes when it 
send the message to the destination. 

The destination MS/LS may refer to the message also after the validity period by using the message reference. The 
message validity time in that sense is application dependent and is outside the scope of the present document. 

The SwMI may control whether the destination may use short form report or not by the short form report information 
element in the SDS-TRANSFER PDU, refer to clause 29.4.3.10. 

The SwMI may control addressing type by the broadcast information element SDS-TL addressing method in the 
SYSINFO PDU, refer to clause 29.3.1. 

29.3.3.3 MS receiving a message 

An incoming message is received as an SDS-TRANSFER PDU which is carried to an MS in D-SDS-DATA PDU. The 
information elements of SDS-TRANSFER PDU are as described in clause 29.4.2.4, table 29.14. The validity period 
information element may have been modified by the SwMI and may use the indicated value when choosing the report 
type or addressing, refer to clause 29.3.3.4.4. 

When an MS SDS-TL entity receives an incoming message, it shall deliver it to the user application or interpret the 
message according to the protocol identifier and, if present, the data coding scheme. The delivery report request shall 
indicate to the MS or user application whether or not an acknowledgement for the message needs to sent back to the 
SwMI. The procedures for sending an acknowledgement as a report are covered in clause 29.3.3.4. The report may also 
contain user data. 

29.3.3.4 Sending an acknowledgement from the destination MS/LS 
29.3.3.4.1 General 

An MS receiving a message shall send an acknowledgement back to the SwMI according to the value of the "Delivery 
report request" information element. Note that the use of the term, "acknowledgement" in this sub-clause refers to an 
SDS-TL data transfer report and not to the layer 2 acknowledgements which may also be sent as part of the underlying 
SDS and LLC transport mechanism which are being used by SDS-TL. Also, the generator of the report should be the 
final destination: if the final destination is a host located on the PEI, then the report should be generated by the host 
connected to the PEI. 

The SDS-REPORT PDU shall be used to send an acknowledgement back to the sender of the message. The "Message 
reference" information element shall be set to be equal to the message reference of the original received message to 
which the acknowledgement refers. The message reference and original source (destination of the SDS-REPORT PDU) 
address uniquely identifies a message so that the report can be matched to the SDS-TRANSFER PDU, which is 
acknowledged, in the SwMI. The message reference may be the only matching element to the SDS-TRANSFER PDU, 
which is acknowledged, in the originator entity as the use of the original destination address is optional. Refer to 
clause 29.3.1 on addressing and clause 29.3.2.5 on message reference. 

Upon receiving an SDS-REPORT PDU, the SwMI should relay this PDU back to the originator of the 
SDS-TRANSFER PDU without other modification than required for addressing and validity period, which SwMI may 
modify. For store and forward networks, the SwMI may temporarily shield the originator from negative 
acknowledgements or modify the report (see clause 29.3.3.6.3); for example, if a memory capacity exceeded delivery 
status is returned from the target, the store and forward entity may shield this report from the originator and retry 
sending the message at a later time within the validity period. The validity period in the SDS-REPORT PDU has no 
meaning to the destination of the SDS-REPORT PDU. The SwMI may use store and forward service, if it is allowed in 
the SDS-REPORT PDU. Note that, as shown in figures 29.6 to 29.8, the application is responsible for sending 
acknowledgements using the TLSDS -REPORT request primitive in accordance with the parameters of the 
TLSDS-TRANSFER indication. The SDS-TL layer simply provides a transport mechanism and PDU definition for 
sending acknowledgements. 
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End-to-end acknowledgements may be requested for both point-to-point and point-to-multipoint message transfers; in 
the case of multipoint transfers an acknowledged service should be used with care due to the amount of air interface 
traffic which could be generated by a large group of MS/LS sending acknowledgements back to the originator. It is 
recommended that point-to-multipoint transfer does not request end-to-end acknowledgement. In fact, the SwMI may 
modify a multi-point transfer (by modifying the "Delivery report request" information element to "No delivery report 
requested" and returning a report to the originator indicating "SDS sent to group, acknowledgements prevented") to 
prevent the destination MS / LS group sending acknowledgements. 

If an acknowledgement is requested for a point-to-multipoint transfer, the SDS message carrying the acknowledgement 
shall contain the individual address of each destination MS (not the group address) and the message reference of the 
original SDS-TRANSFER PDU. It is then the responsibility of the originating application to match the 
acknowledgements to the original sent message using the message reference. 

The sender of the SDS-REPORT PDU may request the recipient to send an SDS-ACK PDU to acknowledge the 
reception of the SDS-REPORT PDU, refer to clauses 29.3.3.5 and 29.3.3.7. 

NOTE: When the destination MS wishes to receive an SDS-ACK PDU to its SDS-REPORT PDU and the next 
node is (non-transparent) SwMI, it may have received other SDS-TRANSFER PDU (from another 
MS/LS) for which it has sent an SDS-REPORT PDU waiting for an SDS-ACK PDU and the message 
reference values of the SDS-TRANSFER PDUs happen to be the same. This can happen as each MS 
allocates independently message references to the SDS-TRANSFER PDUs. In the case of conflict the MS 
may delay the sending of the SDS-REPORT PDU until is receives an SDS-ACK PDU for the previous 
one. 

29.3.3.4.2 Positive acknowledgement from an MS/LS 

If the "Delivery report request" information element in the original SDS-TRANSFER PDU indicates the following 
acknowledgement type: 

• no delivery report requested; 

then the destination application shall simply consume the message and shall not send any acknowledgement back to the 
SwMI. 

If the "Delivery report request" information element in the original SDS-TRANSFER PDU indicates: 

• message receipt report requested; 

and the message is received and successfully decoded, then the destination application shall initiate sending of an 
acknowledgement to the SwMI using the SDS-REPORT PDU. If the SwMI fails to receive this report, it may retry the 
delivery. The mechanism determining when to retry the delivery is outside the scope of the present document. 

When receiving the acknowledgement, the SwMI should relay this back to the original sending MS/LS. In this case the 
"Delivery status" information element shall have the following value: 

• SDS receipt acknowledged by destination. 

If the "Delivery report request" information element in the original SDS-TRANSFER PDU indicates: 

• message consumed report requested; 

and the message is received and successfully decoded, then the destination application shall initiate sending of an 
acknowledgement to the SwMI using the SDS-REPORT PDU when the message is consumed. Determining when a 
message is consumed shall depend on the application which is using the SDS-TL protocol and which is indicated by the 
protocol identifier (see clause 29.4.3.9). In this case the "Delivery status" information element shall have the following 
value: 

• SDS consumed by destination. 

The originator may also request both reports. 

The SwMI may control addressing type of the SDS-REPORT PDU by the broadcast information element SDS-TL 
addressing method, refer to clause 29.3. L 
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29.3.3.4.3 Negative acknowledgement from an MS/LS 

If a destination receives an individually addressed SDS-TL data transfer service PDU and the MS does not support the 
specific SDS-TL protocol, or the message cannot be delivered to the peer application, or the destination does not 
support the application, or the destination cannot receive more messages, then the destination shall issue a negative 
acknowledgement using the SDS-REPORT PDU. Also the peer application may generate some negative 
acknowledgements. These error situations are indicated with the "Delivery status" information element set to one of the 
values outlined in table 29.16 depending on the nature of the error condition (in this table, the MS may return values 
that indicate a "report source" as "destination"). 

Note that, if an error occurs when receiving an individually addressed SDS-TL message, the destination shall send a 
negative acknowledgement regardless of whether or not the originator requested an acknowledgement. If an error 
occurs when receiving a broadcast or group addressed message, the message shall be silently discarded. 

The SwMI may control addressing type by the broadcast information element SDS-TL addressing method, refer to 
clause 29.3.1. 

29.3.3.4.4 Short form acknowledge 

A short form acknowledgement SDS-SHORT REPORT PDU is defined and transferred using SDS STATUS PDUs to 
provide an alternative to using the SDS-REPORT PDU (when using SSI addressing, the short form acknowledgement 
will fit into a single 7i/4-QPSK random access burst on the air interface). The SDS-SHORT REPORT PDU may be used 
to send an acknowledgement from a MS/LS, as described in clauses 29.3.3.4.2 and 29.3.3.4.3 instead of SDS-REPORT 
PDU. 

The SDS-SHORT REPORT PDU may be used when the report is a response to SDS-TRANSFER PDU which contains 
short form report value "Use of short form report recommended during the validity period of the message" and the 
validity period has not expired, refer to clause 29.4.3.10. In this case, the destination MS/LS may choose between the 
SDS-SHORT REPORT PDU and the SDS-REPORT PDU in the cases where the report types available in the short 
form will suffice. In a transparent transfer mode the SDS-SHORT REPORT PDU may be used even though the validity 
period is not included into the reported SDS-TRANSFER PDU. The implied validity time is application dependent and 
outside the scope of the present document. 

The short form acknowledgement should be treated by the SwMI and MS/LS equivalent to the corresponding full 
SDS-REPORT PDU. The SwMI may modify a short report to a standard report for transmission to the original 
originator of the SDS-TRANSFER which is being reported. 

The usage of the SDS-SHORT REPORT PDU is application independent. 

The short form report does not contain the Acknowledgement required information element. The implied value of this 
information element shall be "No further acknowledgements required for this message". 

29.3.3.5 Sending an acknowledgement from the source MS/LS 

An MS receiving an acknowledgement shall if requested send a delivery report back to the SwMI. Note that the use of 
the term, "acknowledgement" in this sub-clause refers to an SDS-TL reports and not to the layer 2 acknowledgements 
which may also be sent as part of the underlying SDS and LLC transport mechanism which are being used by SDS-TL. 
Also, the generator of the acknowledgement should be the final destination of the report: if the final destination is a host 
located on the PEI, then the acknowledgement should be generated by the host connected to the PEL 

The SDS-ACK PDU shall, when required, be used to send an acknowledgement back to the sender of the 
acknowledgement (report). The "Message reference" information element shall be set to be equal to the message 
reference of the original received message to which the acknowledgement refers. The message reference and source 
address (of the SDS-ACK PDU) uniquely identifies the message so that the acknowledgement can be matched to the 
SDS-REPORT PDU in the next node. In the case of transparent SwMI the next node on this protocol point of view is 
the destination MS/LS. 
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If the "Delivery report" information element in the SDS-REPORT PDU indicates: 

• SDS receipt acknowledged by destination; 

and if the "Acknowledgement required" information element indicates that further acknowledgement is needed, then the 
source application shall initiate sending of an acknowledgement to the SwMI using the SDS-ACK PDU. In this case the 
"Delivery status" information element shall have the following value: 

• SDS receipt report acknowledgement. 

If the "Delivery report" information element in the SDS-REPORT PDU indicates: 

• SDS consumed by destination; 

and if the "Acknowledgement required" information element indicates that further acknowledgement is needed, then the 
source application shall initiate sending of an acknowledgement to the SwMI using the SDS-ACK PDU. In this case the 
"Delivery status" information element shall have the following value: 

• SDS consumed report acknowledgement. 

For all negative "Delivery report" information values in the SDS-REPORT PDU and if the "Acknowledgement 
required" information element indicates that further acknowledgement is needed, then the source application shall 
initiate sending of an acknowledgement to the SwMI using the SDS-ACK PDU. In this case the "Delivery status" 
information element shall have the following value: 

• Negative report acknowledgement. 

If the requester fails to receive any of these SDS-ACKs, it may retry the delivery of the SDS-REPORT PDU. The 
mechanism determining when to retry the delivery is outside the scope of the present document. 

29.3.3.6 Sending an acknowledgement from the SwMI 
29.3.3.6.1 General 

In most cases, the SwMI is simply a relay for messages and acknowledgements (reports) sent between an originator and 
destination. An exception to this is the case of an SDS-TRANSFER PDU that cannot be delivered. Note that the use of 
the term, "acknowledgement" in this sub-clause refers to an SDS-TL report and not to the layer 2 acknowledgements 
which may also be sent as part of the underlying SDS and LLC transport mechanism which are being used by SDS-TL. 

The SDS-REPORT PDU shall be used to send an acknowledgement back to the sender of the message. The "Message 
reference" information element shall be set to be equal to the message reference of the SDS-TRANSFER PDU to which 
the acknowledgement refers. The message reference and original source address of the SDS-TRANSFER PDU (i.e. the 
destination of the SDS-REPORT PDU) uniquely identify a message so that the acknowledgement can be matched to an 
SDS-TRANSFER PDU in the next node. The message reference may be the only matching element to the 
SDS-TRANSFER PDU, which is acknowledged, in the originator entity as the use of the original destination address is 
optional. Refer to clause 29.3.1 on addressing and clause 29.3.2.5 on message reference. 

The SDS-ACK PDU shall be used to send an acknowledgement back to the sender of the report, if requested. The 
"Message reference" information element shall be set to be equal to the message reference of the SDS-REPORT PDU to 
which the acknowledgement refers. The message reference and source address uniquely identify the message so that the 
acknowledgement can be matched to the SDS-REPORT PDU. 

NOTE: In this content the SwMI is the entity which is addressed in the basic SDS PDU such as a store and 
forward entity or a service centre. 
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29.3.3.6.2 Positive acknowledgement from the SwMI 

If the SwMI or a service centre forward an SDS-TL message to an external network that does not support the SDS-TL 
services requested by the originator, the SwMI may acknowledge the forwarding of the message. This 
acknowledgement only acknowledges the fact that the message has been forwarded and is not a guarantee for either 
delivery or consumption of the message. 

In this case the "Delivery report" information element in the SDS-REPORT PDU indicates: 

• SDS message forwarded to external network. 

The originator will not receive any further acknowledgements for the message. 

29.3.3.6.3 Negative acknowledgement from the SwMI 

If the SwMI receives an SDS-TL message and the message cannot be delivered to the destination or SwMI detects some 
error condition (for example, source / destination not authorized for SDS or the network is overloaded) or the message 
transfer fails for some reason, then the SwMI should issue a negative acknowledgement to the originator using the 
SDS-REPORT PDU. The "Delivery status" information element is set to one of the values outlined in table 29.16 
depending on the nature of the error condition (in this table, the SwMI may return values that indicate a "report source" 
as "SwMI"). 

In store and forward networks, once the validity period has expired, the store and forward entity or SwMI should return 
an SDS-REPORT with "Delivery status" indicating "validity period expired". The store and forward entity or SwMI 
should not attempt any further deliveries, and the originating MS should not expect to receive any further reports, for a 
given message transmission, once "validity period" has expired. 

Note that, if an error occurs in the message transfer to the destination, the SwMI should send a negative 
acknowledgement regardless of whether or not the originator requested an acknowledgement. 

29.3.3.6.4 Temporary negative acknowledgement from the SwMI 

If the SwMI receives an SDS-TL message and the message cannot be delivered to the destination for a temporary 
reason (for example, destination is not immediately reachable or the network is overloaded), then the SwMI should 
issue a temporary negative acknowledgement to the originator using the SDS-REPORT PDU. The "Delivery status" 
information element is set to one of the values outlined in table 29.16 depending on the nature of the error condition. 

The "Delivery status" information element value "Message stored by SwMI" may be used instead of a specific value. 

On the reception of these reasons MS should expect that the message will be delivered later and should not resend it 
before a further failure indication. 

29.3.3.7 Sending an acknowledgement from the SwMI to destination MS/LS 

An SwMI receiving a report shall if requested send an acknowledgement back to the MS/LS. Note that the use of the 
term, "acknowledgement" in this sub-clause refers to an SDS-TL ACK PDU and not to the layer 2 acknowledgements 
which may also be sent as part of the underlying LLC transport mechanism. For the scenario refer to figures 29.7 and 
29.8. 

The SDS-ACK PDU shall, when required, be used to send an acknowledgement back to the sender of the report. The 
"Message reference" information element shall be set to be equal to the message reference of the report to which the 
acknowledgement refers. Only the message reference uniquely identify the message so that the acknowledgement can 
be matched to the SDS-REPORT PDU in the MS receiving the SDS-ACK PDU. Refer to clause 29.3.1 on addressing 
and clause 29.3.2.5 on message reference. 

If the "Delivery report" information element in the SDS-REPORT PDU indicates: 

• SDS receipt acknowledged by destination 

and if the "Acknowledgement required" information element indicates that an acknowledgement is needed, then the 
SwMI shall initiate sending of an acknowledgement to the MS/LS using the SDS-ACK PDU. In this case the "Delivery 
status" information element shall have the following value: 

• SDS receipt report acknowledgement. 
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If the "Delivery report" information element in the SDS-REPORT PDU indicates: 

• SDS consumed by destination; 

and if the "Acknowledgement required" information element indicates that an acknowledgement is needed, then the 
SwMI shall initiate sending of an acknowledgement to the MS/LS using the SDS-ACK PDU. In this case the "Delivery 
status" information element shall have the following value: 

• SDS consumed report acknowledgement. 

For all negative "Delivery report" information values in the SDS-REPORT PDU and if the "Acknowledgement 
required" information element indicates that an acknowledgement is needed, then the SwMI shall initiate sending of an 
acknowledgement to the SwMI using the SDS-ACK PDU. In this case the "Delivery status" information element shall 
have the following value: 

• Negative report acknowledgement. 

If the requester fails to receive any of these SDS-ACKs, it may retry the delivery of the SDS-REPORT PDU. The 
mechanism determining when to retry the delivery is outside the scope of the present document. 

29.3.3.8 Using SDS-TL for system broadcast messages 

29.3.3.8.1 General 

The SwMI may use SDS-TL to generate messages which contain broadcast information for TETRA MS/LS. This 
service may provide something similar to the GSM cell broadcast service, refer to TS 144 012 [i.2]. 

29.3.3.8.2 Sending a broadcast message 

The SwMI may send a broadcast message at any time using the SDS-TRANSFER PDU and the SDS bearer service. 
The SwMI may send such a message to the broadcast address (OxFFFFFF hexadecimal) or to a group address and it 
may repeat the message at intervals dependent on the application using this service. The SwMI should indicate the 
broadcast address (OxFFFFFF hexadecimal) as the source address of the message to allow MSs to react on, or ignore 
system broadcast messages. 

When the SwMI sends a broadcast message, it shall set the protocol identifier to indicate the type of system broadcast 
information. The system broadcast is thus not limited to text messages, but can be used to transmit other kinds of 
information, e.g. differential GPS information. 

The SwMI shall also set the "Delivery report request" information element to indicate that no delivery report is 
requested since there shall be no acknowledgement associated with this service. 

The "Message reference" information element may be used to indicate different system broadcast messages or it may be 
changed to indicate that the message has changed. 

The "User data" field shall be used in the same way as for point-point and point-to-multipoint transfer described in 
clause 29.3.3.2. 

29.3.3.8.3 Receiving a broadcast message 

The MS / LS shall attempt to decode the message according to the protocol identifier and data coding scheme indicated 
in the header. If the message is a text message and the MS / LS is configured to receive system broadcast messages, 
then the message may be displayed to the user as it is received. 
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29.4 Coding requirements 
29.4.1 PDU general structure 

The PDUs detailed in clauses 29.4.2.1 to 29.4.2.4 and in clause 29.5 are sub-PDUs of SDS type 4, embedded in the 
"User defined data-4", refer to clause 14.8.52. The first information element within the "User defined data-4" shall be a 
protocol identifier. This information element shall identify the application using SDS and the protocol used. The 
applications using protocol identifiers in the range IOOOOOOO2 to IIIIIIII2 shall use the PDUs described in this clause. 
Applications using protocol identifiers in the range from OOOOOOOO2 to0111111l2 shall not use the SDS-TL data 
transport service protocol (see table 29.21). The PDU descriptions for some of these protocol identifiers are defined in 
clause 29.5 and the others are outside the scope of the present document. 

The general format of the SDS-TL PDU inside the "User defined data-4" information element is defined according to 
the annex E. 

The information elements shall be transmitted in the order specified by the table with the top information element being 
transmitted first (before interleaving). The content of an information element is represented by a binary value and the 
most significant bit of that binary value shall be transmitted first (before interleaving). 

Table 29.10: PDU layout 



Information element 


Length 


Value 


Remark 


Protocol identifier 


8 




Refer clause 29.4.3.9 


Type 1 information element (1) 


variable 




See definitions in annex E 


Type 1 information element (2) 


variable 




See definitions in annex E 


etc. 


etc. 




etc. 


Type 1 information element (n) 


variable 




See definitions in annex E 



The SDS-TL PDUs are intended to be byte-aligned for easier handling by the application. The information elements 
may be a part of a byte or combination of multiple bytes. There shall be no O-bits or P-bits in the SDS-TL PDUs and 
the SDS-TL PDU shall fill the whole user data type 4 information element in the D-SDS DATA and U-SDS DATA 
PDUs. 

Information element lengths, values and contents are specified in clause 29.4.2. 

The information contained in the following PDU description tables corresponds to the following key: 

• Length: length of the information element in bits; 

• Type: information element type as defined above; 

• C/O/M: conditional/optional/mandatory information in the PDU; 

• Remark: comment. 

29.4.2 PDU Descriptions 

The PDU described in this clause all have mandatory and conditional information elements. However, it should be 
noted that the entire SDS-TL is not used for some protocol identifiers but only the protocol identifier, refer to 
clause 29.4.3.9. The mandatory elements are thus only mandatory in the case where the SDS-TL is used. 



29.4.2.1 SDS-ACK 

• Response to: 

• Response expected: 

• Short description: 

• PDU carrier: 



SDS-REPORT PDU 

This PDU shall be used to acknowledge previously received SDS delivery report 
U/D-SDS DATA PDU User defined data-4 information element. 
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Table 29.11 : SDS-ACK PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Protocol identifier 


8 




M 




IVIessage type 


4 




M 


SDS-ACK 


Reserved 


4 




M 


See note 


Delivery status 


8 




M 




IVIessage reference 


8 




M 




NOTE: This field is inserted to ensure that the following information elements are aligned to octet 
boundaries. In this edition of the present document the field shall be set to "00002". 



29.4.2.2 SDS-REPORT 

• Response to: -/SDS -TRANSFER PDU 

• Response expected: -/SDS-ACK PDU 

• Short description: 



PDU carrier: 



This PDU shall be used to report on the progress of previously received SDS 
data. 

U/D-SDS DATA PDU User defined data-4 information element. 
Table 29.12: SDS-REPORT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Protocol identifier 


8 




M 




Message type 


4 




M 


SDS-REPORT 


Acknowledgement required 


1 




M 




Reserved 


2 




M 


See note 1 


Storage 


1 




M 




Delivery status 


8 




M 




Message reference 


8 




M 


See note 2 


Validity period 


5 




C 


See note 3 


Forward address type 


3 




C 


See note 3 


Forward address short number address 


8 




C 


See note 4 


Forward address SSI 


24 




C 


See note 4 


Forward address extension 


24 




C 


See note 4 


Number of external subscriber number digits 


8 




C 


See notes 4 and 5 


External subscriber number digit 


4 




C 


See note 6 


User data 


variable 







See note 7 


NOTE 1 : This field is inserted to ensure that the following information elements are aligned to octet boundaries. 
The field shall be set to "OO2" by default. 

NOTE 2: The value shall be the same as defined by the original source of the PDU. 

NOTE 3: This information element shall be present in the PDU only when the "Storage" information element 
indicates storage service. 

NOTE 4: This information element shall be present only when the Forward address type information element is 
present and indicates an address type that requires presence of the information element. 

NOTE 5: The number of external subscriber number digits shall be between 1 and 24 digits. 

NOTE 6: This information element shall be present only when the number of external subscriber digits 
information element is present and it shall contain as many digits as defined in that information 
element. When the Number of external subscriber number digits information element indicates an odd 
value the last digit of the external subscriber number shall be followed by an additional digit set to "0" 
and that additional digit shall not be a part of the external subscriber number. 

NOTE 7: This information element is marked to be type 1 and optional on purpose so that there is no 0-bit or 
P-bit before it but the user data length may be zero. 
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Short description: 
PDU carrier: 



This PDU shall be used to report on the progress of previously received SDS 
data 

U/D-STATUS PDU Pre-coded status information element 
Table 29.13: SDS-SHORT REPORT PDU contents 



Information element 


Length 


Value 


Remark 


SDS-TL PDU 


6 


01111I2 


This status message belongs to the SDS-TL protocol 


Short report type 


2 


any 




Message reference 


8 


any 


The same value as in the corresponding request PDU 


NOTE: The short form acknowledgement does not contain the Acknowledgement required information element. The 
implied value of this information element defaults to "No further acknowledgements required for this 
message". 



29.4.2.4 SDS-TRANSFER 

• Response to: 

• Response expected: -/SDS-REPORT 

• Short description: This PDU shall be used to send SDS data 

• PDU carrier: U/D-SDS DATA PDU User defined data-4 information element. 

Table 29.14: SDS-TRANSFER PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Protocol identifier 


8 




M 




Message type 


4 




M 


SDS-TRANSFER 


Delivery report request 


2 




M 




Service selection / Short form report 


1 




M 




Storage 


1 




M 




Message reference 


8 




M 


See note 1 


Validity period 


5 




C 


See note 2 


Forward address type 


3 




C 


See note 2 


Forward address short number address 


8 




C 


See note 3 


Forward address SSI 


24 




C 


See note 3 


Forward address extension 


24 




C 


See note 3 


Number of external subscriber number digits 


8 




C 


See notes 3 and 4 


External subscriber number digit 


4 




C 


Repeatable, see note 5 


Dummy digit 


4 




C 


See note 6 


User data 


variable 


1 


M 




NOTE 1 : The value shall be defined by the original source of the PDU. 

NOTE 2: This information element shall be present only, when Storage information element indicates storage 

service. 
NOTE 3: This information element shall be present only, when Forward address type information element is 

present and indicates address type that requires presence of the information element. 
NOTE 4: The length shall be between 1 and 24, refer to clause 14.8.20. 
NOTE 5: This information element shall be present only, when the number of external subscriber number digits 

information element is present and it shall be present as many times as defined by the number of 

external subscriber number digits information element. 
NOTE 6: This information element shall be present only when the Number of external subscriber number digits 

information element indicates an odd value. When present the Dummy digit shall be set to "0". The 

Dummy digit shall not be a part of the external subscriber number. For encoding of each digit refer to 

clause 14.8.20. 
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29.4.3 Information elements coding 
29.4.3.1 Acknowledgement required 

The Acknowledgement required information element shall indicate as defined in table 29.15 if an SDS-REPORT PDU 
needs further acknowledgement by an SDS-ACK PDU. This may be requested by either the originator or by the SwMI 
or service centre if needed. 

Table 29.15: Acknowledgement required information element contents 



Information element 


Length 


Value 


Remark 


Acknowledgement 
required 


1 


02 


No further acknowledgements required for this message 


12 


Acknowledgement required for this message 



ETSI 



1064 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



29.4.3.2 Delivery status 

The Delivery status information element in SDS-REPORT and SDS-ACK PDUs shall indicate as defined in table 29.16 
the status of a previously sent SDS-TRANSFER PDU for which a delivery report has been requested. This information 
element is also used to communicate error information to an MS/LS when SDS data transfer fails. The "Report source" 
column in the table 29.16 shall indicate whether the status value can be used in a status report sourced by the SwMI or 
the destination for the message transfer or both. Note that a status report generated by the destination may be relayed 
back to the originator by the SwMI but this report is still classified as being sourced by the destination. 

Table 29.16: Delivery status information element contents 



Information element 



Length 



Value 



Remark 



Report source 



Delivery status 



8 



OOOXXXXX2 



SDS data transfer success 



OOOOOOOOp 



SDS receipt acl<nowledged by 
destination 



Destination 



00000001c 



SDS receipt report acknowledgement 



SwM I/Source 



00000010? 



SDS consumed by destination 



Destination 



00000011; 



SDS consumed report 
acknowledgement 



SwM I/Sou roe 



000001 OO2 



SDS message forwarded to external 
network 



SwMI 



00000101; 



SDS sent to group, acknowledgements 
prevented 



SwMI 



000001 IO2 to 
OOOIIIII2 



Reserved 



OOIXXXXX0 



Temporary error, SwMI still trying to 
transfer SDS data 



OOlOOOOOp 



Congestion, message stored by SwMI 



SwMI 



00100001; 



message stored by SwMI 



SwMI 



001 0001 O2 



001 00011 2 to 
OOIIIIII2 



Destination not reachable, message 
stored by SwMI 



SwMI 



Reserved 



OIOXXXXX2 



SDS data transfer failed, SwMI is not 
making any more transfer attempts 



OlOOOOOOp 



Network overload 



SwMI 



01000001; 



Service permanently not available on 
BS 



SwMI 



01 00001 Op 



Service temporary not available on BS 



SwMI 



01000011; 



Source is not authorized for SDS 



SwMI 



OlOOOIOOp 



Destination is not authorized for SDS 



SwMI 



01000101; 



Unknown destination, gateway, or 
service centre address 



SwMI 



010001 lOp 



Unknown forward address 



SwMI 



01000111; 



Group address with individual service 



SwMI 



OlOOIOOOp 



Validity period expired, message not 
received by far end 



SwMI 



01001001; 



Validity period expired, message not 
consumed by far end 



SwMI 



OlOOIOlOp 



Delivery failed 



OIOOIOII2 



OlOOIIOOp 



Destination not registered on system 



SwMI 



SwMI 



Destination queue full 



SwMI 



01001101; 



OIOOIIIO2 



Message too long for destination or 
gateway 



SwMI/Destination 



Destination does not support SDS-TL 
data transfer service PDUs 



SwMI/Destination 



OIOOIIII2 



Destination host not connected 



Destination 



OIOIOOOO2 



Protocol not supported 



Destination 



01010001; 



Data coding scheme not supported 



Destination 
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Information element 



Length 



Value 



Remark 



Report source 



01010010p 



Destination memory full, message 
discarded 



Destination 



01010011; 



OlOIOIOOp 



Destination not accepting SDS 
messages 



SwIVII 



Reserved 



OIOIOIOI2 



Reserved 



OIOIOIIO2 



Destination address administratively 
prohibited 



SwIVII 



OIOIOIII2 



Can not route to external network 



SwIVII 



OlOIIOOOp 



Unknown external subscriber number 



SwIVII 



OIOIIOOI2 



Negative report acknowledgement 



Source 



OIOIIOIO2 



Destination not reachable, 
delivery failed 



message 



SwMI 



OIOIIOII2 



Text distribution error, message 
discarded 



Destination 



OIOIIIOO2 



Corrupt information element, message 
discarded 



Destination 



0101110l2to 
OIOIIIII2 



Reserved 



OIIXXXXX2 



Flow control messages 



01100000? 



Destination memory full 



Destination 



01100001; 



Destination memory available 



Destination 



01100010? 



Start pending messages 



Destination 



01100011? 



No pending messages 



SwIVII 



01 1001 00? to 
01111111? 



Reserved 



1 0OXXXXX? 



End to end control messages 



10000000? 



Stop sending 



Destination 



10000001; 



Start sending 



Destination 



10000010? to 
10011111? 



Available for user application definition, 
(see note) 



Destination 



101XXXXX?to 
111XXXXX? 



Reserved for future use 



NOTE: These values may be co-ordinated outside the scope of the present document in order to prevent 
clashed. 



29.4.3.3 Delivery report request 

The Delivery report request information element shall indicate as defined in table 29.17 the type of delivery report 
which is being requested by the sender of SDS -TRANSFER PDU. This delivery report may be generated either by the 
SwMI or the destination for the message depending on the type of report. Note that this information element is a bitmap 
to allow multiple combinations of the types of report (end-to-end acknowledgement) to be requested. 

Table 29.17: Delivery report request information element contents 



Information element 


Length 


Value 


Remark 


Delivery report request 


2 


00? 


No delivery report requested 


01? 


Message received report requested (see note 1) 


10? 


Message consumed report requested (see note 2) 


11? 


Message received and consumed report requested 


NOTE 1 : This delivery report type shall indicate that the sender of the message is requesting a report when the 

message has been received by the destination. 
NOTE 2: This delivery report type shall indicate that the sender of the message is requesting a report when the 

message has been consumed by the destination. A message is consumed when the application 

processes the message. For example, in the case of text messaging, a message is consumed when 

the user reads the message. 
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29.4.3.4 Dummy digit 

The Dummy digit information element shall fill unused 4 bits in the case of an odd number of digits in the address 
information element in order to keep octet boundaries. The only applicable value of the digit shall be "OOOO2" and all 
other values shall be reserved. 

29.4.3.5 Forward address type 

The Forward address type information element shall indicate as defined in table 29.18 the type of address in the 
"Forward address" information element. 

NOTE: The usage of a short number address as a forward address requires that the SwMI (store and forward 

entity or service centre) to which MS addresses the U-SDS-DATA PDU supports supplementary service 
SS-SNA for the sending MS, refer to EN 300 392-10-7 [i.4], EN 300 392-1 1-7 [i.5] and 
EN 300 392-12-7 [13]. 

Table 29.18: Forward address type information element contents 



Information element 


Length 


Value 


Remark 


Forward address type 


3 


OOO2 


Short Number Address (SNA) (see note 1) 


001 2 


Short Subscriber Identity (SSI) 


01 O2 


TETRA Subscriber Identity (TSI) 


0112 


External subscriber number 


1002 


Reserved 


1012 


Reserved 


1102 


Reserved 


1112 


No forward address present (see note 2). 


NOTE 1 : The short number addressing is applicable only in messages from an IVIS to SwMI direction. 
NOTE 2: Refer to clause 29.3.1 for usage of this value. 



29.4.3.6 



Forward address 



The Forward address information element, if present, is one of SNA, SSI or TSI as defined in EN 300 392-1 [6], 
clause 7 or an External subscriber number. The forward address may be used to convey the true source / destination 
address to a network service point or service user. 

29.4.3.7 IVIessage reference 

The message reference information element shall give as defined in table 29.19 an integer representation of a reference 
number of an SDS-TRANSFER PDU submitted to the SwMI by an MS/LS. 

Table 29.19: Message reference information elements contents 



Information element 


Length 


Value 


Remark 


IVIessage reference 


8 


000000002to1111111l2 


to 255 
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29.4.3.8 Message type 

The Message type information element shall identify as defined in table 29.20 the SDS-TL message type being 
conveyed by the SDS user defined data service. 

Table 29.20: Message type information element contents 



Information element 


Length 


Value 


Remark 


Message type 


4 


OXXXg 


IVIessage transfer protocol is defined by SDS-TL 


00002 


SDS-TRANSFER 


00012 


SDS-REPORT 


001 O2 


SDS-ACK 


0011 2 to 

01112 


Reserved for additional message types 


1XXX2 


Defined by application (see note) 


NOTE: In this case, the format of the SDS user data shall be defined by the application and not necessarily 
conforming to this transport protocol standard. 
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29.4.3.9 



Protocol identifier 



The Protocol identifier information element shall refer to the user application utilizing the SDS-TL protocol as defined 
in table 29.21. 

Table 29.21 : Protocol identifier information element contents 



Information element 



Length 



Value 



Remark 



Clause 



Protocol identifier 



8 



OOOOOOOO2 



Reserved, (see notes 1 and 2) 



00000001; 



0000001 Oo 



OTAK (Over The Air re-Keying for end to end 
encryption), refer to EN 300 392-7 [8] V2.1 .1 
clause 7.6 or ES 202 109 [3] clause 4.6, (see 
notes 2 and 3) 



29.5.1 



Simple Text Messaging, (see note 2) 



29.5.2 



00000011; 



Simple location system, (see note 2) 



29.5.5 



000001 OOp 



Wireless Datagram Protocol WAP, (see note 2) 



29.5.8 



00000101; 



Wireless Control IVIessage Protocol WCIVIP, (see 
note 2) 



29.5.8 



000001 IO0 



M-DMO (Managed DM0), refer to 
EN 300 396-10 [26], (see note 2) 



29.5.1 



00000111; 



PIN authentication, (see note 2) 



29.5.1 



00001 OOOo 



End-to-end encrypted message, (see notes 2 and 6) 



00001001; 



Simple immediate text messaging, (see note 2) 



29.5.2 



00001 01 Op 



Location information protocol, (see note 2) 



29.5.12 



00001011; 



Net Assist Protocol (NAP), (see note 2) 



29.5.13 



00001 lOOsto 
OOIIIIII2 



Reserved for future standard definition, (see note 2) 



29.5.1 



010000002to 
OIIIIIIO2 



Available for user application definition, (see notes 2 
and 4) 



29.5.1 



OIIIIIII2 



Reserved for extension, (see notes 2 and 7) 



1 0OOOOOO2 to 
10000001 2 



Reserved, (see note 5) 



10000010? 



Text Messaging, (see note 5) 



29.5.3 



10000011; 



Location system, (see note 5) 



29.5.6 



100001 OOp 



Wireless Datagram Protocol WAP, (see note 5) 



29.5.8 



10000101; 



Wireless Control Message Protocol WCMP, (see 
note 5) 



29.5.8 



1000011 Op 



M-DMO (Managed DM0), refer to 
EN 300 396-10 [26], (see note 5) 



29.5.1 



10000111; 



Reserved for future standard definition, (see note 5) 



IOOOIOOO2 



End-to-end encrypted message, (see notes 5 and 6) 



10001001; 



Immediate text messaging, (see note 5) 



29.5.3 



10001010p 



Message with User Data Header 



29.5.9 



10001 Oil 2 to 
IOIIIIII2 



Reserved for future standard definition, (see note 5) 



1 1 0OOOOO2 to 
IIIIIIIO2 



Available for user application definition, (see notes 4 
and 5) 



IIIIIIII2 



Reserved for extension, (see notes 5 and 7) 



NOTE 1 
NOTE 2 
NOTE 3 

NOTE 4: 

NOTE 5 
NOTE 6 
NOTE 7 



This protocol identifier value should not be used as it is not allocated for a pre-defined application. 

The SDS-TL data transfer service shall not be used for these protocol identifiers, refer to clause 29.4.1 . 

In the EN 300 392-7 [8] clause 7.6 or ES 202 109 [3] clause 4.6 the protocol identifier is identified as 

"SDS type 4 header". 

The assignment of these protocol identifiers will be co-ordinated in order to prevent clashes, refer to 

annex J. 

The SDS-TL data transfer service shall be used for these protocol identifiers. 

Refer to TETRA MoU SFPG recommendation 07 for information. 

This value shall indicate that the next 8 bits long value is the protocol identifier and the 16 bits replaces 

the eight bits of the protocol identifier in the PDUs using this extension method. 
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29.4.3.10 Service selection/short form report 

The Service selection information element shall indicate as defined in table 29.22 on the uplink if the message is 
allowed to be sent to a group address and on the downlink whether a short form report is allowed for this message. If 
the value of this information element is set to "individual service" when the destination address is a group address, the 
SwMI may reject the message. 

Table 29.22: Service selection/ short form report information element contents 



Information element 


Length 


Value 


Remark 


Service selection / short 
form report 


1 


02 


Uplink: Individual service 

Downlink: Use of short form report recommended during the 

validity period of the message 


12 


Uplink: Group or individual service 
Downlink: Only standard report allowed 



29.4.3.1 1 Short report type 

The Short report type information element shall indicate the reason for report as defined in table 29.23. 
Table 29.23: Short report type information element contents 



Information element 


Length 


Value 


Remark 


Short report type 


2 


OO2 


Protocol/encoding not supported 


OI2 


Destination memory full 


IO2 


Message received 


II2 


IVIessage consumed 



29.4.3.12 Storage 

The Storage information element shall indicate as defined in table 29.24 if the SwMI is allowed to store the message 
longer than needed for ordinary processing. If storage is allowed, the "Validity period" and "Forward address" 
information elements are present. 

Table 29.24: Storage information element contents 



Information element 


Length 


Value 


Remark 


Storage 


1 


O2 


Storage not allowed 


I2 


Storage allowed 



29.4.3.13 User data 

The User data information element contains the application data which is coded according to the protocol identified by 
the Protocol identifier and, if present, the data coding scheme information elements. 
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29.4.3.14 Validity period 

The Validity period information element shall indicate the length of time after receiving an SDS-TRANSFER PDU that 
the SwMI should attempt to deliver the message. If this time expires, the SwMI shall stop delivery attempts and may 
report message failure to the sending MS. The values shall be as defined in table 29.25. The maximum error of the 
validity period should be less than 40 %. 



Table 29.25: Validity period information element contents 



Information element 


Length 


Value 


Remark 


Validity period (VP) 


S 





No validity period, (see note 1) 


1 to 6 


VP X 10 seconds, (see note 2) 


7 to 10 


(VP - S) X 1 minute, (see note 3) 


11 to 16 


(VP - 10) X 10 minutes, (see note 4) 


17 to 21 


(VP- IS) X 1 hour, (see note S) 


22 to 24 


(VP - 20) X 6 hours, (see note 6) 


25 to SO 


(VP - 24) X 2 days, (see note 7) 


31 


Infinite validity period, (see note S) 


N0TE1 
NOTE 2 
NOTES 
NOTE 4 
NOTES 
NOTE 6 
NOTE 7 
NOTES 


In this case, the SwIVII should attempt to deliver the message. If unsuccessful 
10 second intervals up to 60 seconds. 
1 minute intervals up to 5 minutes. 
10 minute intervals up to 1 hour. 

1 hour intervals up to 6 hours. 
6 hour intervals up to 24 hours. 

2 day intervals up to 1 2 days. 

In this case, the SwIVII should attempt to deliver the message until expiry of a 
maximum time. 


the message is dropped, 
network dependant 



29.5 Protocol specific definitions 

This clause defines information elements specific to the some of the standardized protocol identifiers. 

29.5.1 Standardized protocols using SDS Type 4 without SDS-TL 

For TETRA some services use SDS type 4 without SDS-TL data transport service as information carrier. Some of these 
protocols will be defined in other TETRA standards such as OTAR for the end-to-end encryption key management 
mechanism. 

29.5.1.1 Protocol sequences 

These protocols shall not use the SDS-TL acknowledgement and store and forward services. For protocol sequences 
refer to references in table 29.21. 

29.5.1 .2 PDU Description tables 

The minimum standardized information element of these "simple" protocols defined in clause 29 is the protocol 
identifier. For all other aspects refer to the specific protocol as indicated in the table 29.21. The standardized simple 
protocol PDUs shall be constructed as defined for the User Defined Data-4 information element in clause 14.8.52. Thus 
the minimum information elements shall be as defined in table 29.26 unless more elements are defined in the specific 
protocol description. 

Table 29.26: Standardized "simple" protocol PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Protocol identifier 


S 


1 


M 


Refer to table 29.21 


Protocol information 


variable 


1 


M 
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29.5.2 Simple text messaging 



The Simple text message protocol is intended to be a very basic text messaging application defined to a degree where 
interoperability can be expected. Mechanisms how Simple text messages are presented to the user is outside the scope 
of the present document. 

When a mobile terminated text message is indicated to be a Simple immediate text message and the MS has the 
capability of displaying short messages, the MS shall display the message immediately. Otherwise the protocol for 
Simple immediate text messaging is the same as in case of normal simple text messaging. If the MS is incapable of 
displaying Simple immediate text messages, they can be handled as a normal simple text message. 

29.5.2.1 Protocol sequences 

Simple text message protocol does not use any end-to-end acknowledgement or store and forward mechanisms. The 
only delivery acknowledgement mechanisms offered is the layer 2 acknowledge independently on each hop. 

29.5.2.2 PDU description tables 

Simple text messaging does not use the SDS-TL data transfer service PDUs, but defines a protocol specific field to 
specify the data format, refer to 29.5.4.1. The basic SDS type-4 information element shall contain elements as defined 
in clause 29.5.2.3, refer to clause 14.8.52. 

29.5.2.3 Simple text messaging 

• Response to: 

• Response expected: 

• Short description: This PDU shall be used to send simple text messaging SDS data 

• PDU carrier: 

Table 29.27: Simple text messaging PDU contents 



Information element 


Length 


Type 


C/O/IVI 


Remark 


Protocol identifier 


8 


1 


M 


Refer to table 29.21 


Reserved 


1 


1 


M 


See note 1 


Text coding sclieme 


7 


1 


M 


As defined in table 29.29 


Text 


variable 


1 


M 


See note 2 


NOTE 1 : This information element is added in order to keep octet boundaries and to align encoding with 
the text messaging, refer to clause 29.5.3.3 where the timestamp used information element is 
in the position. The value of this information element shall be set to "0". 

NOTE 2: The text shall be encoded as defined in the text coding scheme information element. 



29.5.3 Text messaging using SDS-TL 

The text message protocol offers either a store and forward mechanism in the SwMI or acknowledgements (reports) 
from destination or both as selected by the originating MS/LS. Mechanisms how normal text messages are presented to 
the user is outside the scope of the present document. 
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When a mobile terminated text message is indicated to be an Immediate text message and the MS has the capability of 
displaying short messages, the MS shall display the message immediately. Otherwise the protocol functionality for 
Immediate text messaging is the same as in case of normal text messaging. If the MS is incapable of displaying 
Immediate text messages, they can be handled as a normal text message. For Immediate text messages a message 
consumed report shall be sent only after the user has performed an action that can be taken as an indication that the 
Immediate text message is read. The related man machine actions are outside the scope of the present document. 

29.5.3.1 Protocol sequences 

The protocol sequences of text messaging shall be the unmodified protocol sequences defined in clause 29.3.3. 

29.5.3.2 PDU description tables 

The text messaging protocol uses the full SDS-TL data transport service protocol. The text messaging protocol defines 
additional information elements which are transported in the SDS-TRANSFER PDU. 

29.5.3.3 Text message transfer SDU 

The text message transfer is done by use of an SDS-TRANSFER PDU with additional information elements embedded 
in the user data portion of the SDS-TRANSFER PDU. The SDU part as defined in table 29.28 shall be the user data in 
the SDS-TRANSFER PDU, refer to table 29.14. 

Table 29.28: Text message transfer SDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Time stamp used 


1 


1 


M 


As defined in table 29.41 (see note 1 ) 


Text coding sclieme 


7 


1 


M 


As defined in table 29.29 (see note 1) 


Time stamp 


24 


1 


C 


As defined in table 29.40 (see note 2) 


Text 


variable 


1 


M 


See note 3 


NOTE 1 : These two elements can be processed together in order to l<eep byte alignment. 

NOTE 2: This information element shall be present only, when the Time stamp used indicates the presence of 

timestamp. 
NOTE 3: The text shall be encoded as defined in the text coding scheme information element. 



29.5.3.4 Text message short form acknowledgement 

The text messaging may use the SDS-SHORT REPORT PDU as defined in clause 29.4.4.4. 

The destination MS/LS can choose between the SDS-SHORT REPORT PDU and the SDS-REPORT PDU in the cases 
where the report types available in the short form will suffice, refer to clause 29.3.3.4.4. 

29.5.4 Text messaging information elements 
29.5.4.1 Text coding scheme 

The text coding of the user data in an SDS message shall be specified by the Text coding scheme information element. 
The text coding schemes defined in the present document are: 

• 7-bit alphabet; 

• 8 -bit alphabets; 

• UCS-2 with the UTF-16BE extension. 

The 7-bit alphabet is identical to the GSM default alphabet, refer to TS 100 900 [1] and this is the 7-bit alphabet which 
shall be used by the TETRA SDS-TL service defined in the present document. 

The 8-bit alphabets defined in the present document are a broad range of available alphabets produced by 
ISO/IEC 8859 [40], supporting character sets for multiple languages. 
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The UCS2 alphabet is coded according to the 16-bit UCS2 standard produced by ISO, refer to ISO/IEC 10646 [41] and 
the Unicode Standard in the annex L Bibliography. This alphabet supports an enhanced selection of characters to 
support non-Latin languages and is set to become the basic coding form for all 16 bit and 32-bit computer systems 
during 1997. This alphabet is also supported by GSM. 

The text coding scheme shall be as defined in table 29.29. 

NOTE: The timestamp used, refer table 29.41, and the text coding scheme information elements could be 
processed together in order to keep byte alignment in the protocol. 

Table 29.29: Text coding scheme information element contents 



Information element Length Value 



Remark 



Text coding scheme 



OOOOOOOp 



7-bit alphabet, see clause 29.5.4.3 



0000001; 



ISO/IEC 8859-1 Latini (8-bit) alphabet [40] 



000001 Op 



ISO/IEC 8859-2 Latin2 (8-bit) alphabet [40] 



0000011; 



ISO/IEC 8859-3 Latin3 (8-bit) alphabet [40] 



00001 GOo 



ISO/IEC 8859-4 Latin4 (8-bit) alphabet [40] 



0000101; 



ISO/IEC 8859-5 Latin/Cyrillic (8-bit) alphabet [40] 



00001 lOo 



ISO/IEC 8859-6 Latin/Arabic (8-bit) alphabet [40] 



0000111; 



ISO/IEC 8859-7 Latin/Greek (8-bit) alphabet [40] 



0001 OOOo 



ISO/IEC 8859-8 Latin/Hebrew (8-bit) alphabet [40] 



0001001; 



ISO/IEC 8859-9 Latin5 (8-bit) alphabet [40] 



OOOIOlOp 



ISO/IEC 8859-10 Latin6 (8-bit) alphabet [40] 



0001011; 



ISO/IEC 8859-13 Latin7 (8-bit) alphabet [40] 



0001 lOOp 



ISO/IEC 8859-14 Latin8 (8-bit) alphabet [40] 



0001101; 



ISO/IEC 8859-15 Latin9/Latin0 (8-bit) alphabet [40], see note 1 



0001 llOo 



PC code page 437 (United States) 



0001111; 



PC code page 737 (Greek II) 



OOlOOOOp 



PC code page 850 (Latin I) 



0010001; 



PC code page 852 (Eastern Europe/Latin II) 



OOlOOlOp 



PC code page 855 (Cyrillic I) 



0010011; 



PC code page 857 (Turkish) 



OOIOIOO2 



PC code page 860 (Portuguese) 



0010101; 



PC code page 861 (Icelandic) 



OOlOllOp 



PC code page 863 (Canadian/French) 



0010111; 



PC code page 865 (Nordic) 



OOllOOOp 



PC code page 866 (Russian/Cyrillic II) 



0011001; 



PC code page 869 (Greek) 



OOIIOIO2 



ISO/IEC 10646-1 [41] UCS-2/UTF-16BE (16-bit) alphabet 



0011011; 



Reserved 



etc. 



etc. 



OOIIIII2 



Reserved 



OlOOOOOp 



Available for user application definition, see note 2. 



etc. 



etc. 



IIIIIII2 



Available for user application definition, see note 2 



NOTE 1 : ISO/IEC 8859-1 5 [40] (known both as Latin9 and LatinO) is based on ISO/IEC 8859-1 [40] and contains 

e.g. "€" character. 
NOTE 2: Identities of these text coding schemes should be allocated by a central body in order to support 
interoperability. 



The "7-bit alphabet" shall indicate that the user data is coded using the 7-bit alphabet given in clause 29.5.4.3. When 
this alphabet is used, the characters of the message are packed into octets so that 285 characters can be transported in 
250 bytes of user data. The support of the 7-bit alphabet is optional for MS equipment supporting the SDS-TL service. 

Several 8-bit alphabets are listed as well, however, the list is very long and it is unlikely that an MS will support all 
8-bit coding schemes. In case the MS receives a message in an unknown alphabet, the MS may reject the message or 
map the unsupported alphabet to an alphabet supported by the MS. 
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The UCS-2 alphabet indicates that the user data is coded according to the UCS-2 coding scheme, employing the 
UTF-16 extension of ISO/IEC 10646 [41] using the "BE" (Big Endian) form. While using SDS-TL the Byte Order 
Mark (BOM) shall not be used as "BE" format shall be the only format defined. 

UTF-16BE uses two consecutive values to represent a character beyond the Basic Multilingual Plane (i.e. Plane 00). As 
the "BE" form is stated, the "value" for the high-half zone (D800-DCFF) shall precede the "value" for the low-half zone 
(DBOO-DFFF), refer to ISO/IEC 10646 [41]. 

29.5.4.2 Character packing 

A 7-bit character number a is represented as shown in table 29.30. 

Table 29.30: 7-bit character presentation 



b7 


b6 


b5 


b4 


b3 


b2 


b1 


aa 


ab 


ac 


ad 


ae 


af 


ag 



A 7-bit character number a has bit "a" as the most significant bit "b7" and bit "g" as the least significant bit "bl". 

For the 7-bit alphabet, characters shall first be packed into octets according to TS 100 900 [1] and then inserted 
octet-by-octet into the user data information element. The unused part of the last octet shall be padded by zeros, if 
needed. 

Tables 29.31 to 29.33 present examples of the 7-bit character packing into octets, refer to TS 100 900 [1] 
clause 6.1.2.1.1 for further examples. 

Table 29.31 : One 7-bit character in one octet 





Bits number 




7 


6 


5 


4 


3 


2 


1 





1 Octet 1 





1a 


1b 


1c 


Id 


1e 


If 


1q 



Table 29.32: Two 7-bit characters in two octets 





Bits number 




7 


6 


5 


4 


3 


2 


1 





Octet 1 


2q 


la 


lb 


1c 


Id 


1e 


If 


ig 


Octet 2 








2a 


2b 


2c 


2d 


2e 


2f 



Table 29.33: Seven 7-bit characters in seven octets 





Bits number 




7 


6 


5 


4 


3 


2 


1 





Octet 1 


2q 


la 


lb 


1c 


Id 


1e 


1f 


iq 


Octet 2 


3f 


3q 


2a 


2b 


2c 


2d 


2e 


2f 


Octet 3 


4e 


4f 


4q 


3a 


3b 


3c 


3d 


3e 


Octet 4 


5d 


5e 


5f 


5g 


4a 


4b 


4c 


4d 


Octet 5 


6c 


6d 


6e 


6f 


6g 


5a 


5b 


5c 


Octet 6 


7b 


7c 


7d 


7e 


7f 


7g 


6a 


6b 


Octet 7 























7a 



NOTE: If the last octet contains 7 padding zeros those can be misinterpreted as an " @" character, refer to 
table 29.33. In that case use of Carriage Return character instead of zero padding will prevent 
presentation of the " @ " character. 

The octets containing 7-bit characters shall be set into the user data information element as shown in table 29.34 for the 
case of four 7-bit characters. 
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Table 29.34: Character packing for 7-bit alphiabet 





Octet 1 


Octet 2 


Bit position 


n 


n-1 


n-2 


n-3 


n-4 


n-5 


n-6 


n-7 


n-8 


n-9 


n-10 


n-11 


n-1 2 


n-1 3 


n-1 4 


n-15 


Character bit 


2g 


1a 


1b 


1c 


Id 


1e 


If 


1q 


3f 


3g 


2a 


2b 


2c 


2d 


2e 


2f 




Octet 3 


Octet 4 


Bit position 


n-16 


n-1 7 


n-1 8 


n-1 9 


n-20 


n-21 


n-22 


n-23 


n-24 


n-25 


n-26 


n-27 


n-28 


n-29 


n-30 


n-31 


Character bit 


4e 


4f 


4g 


3a 


3b 


3c 


3d 


3e 














4a 


4b 


4c 


4d 



NOTE: In GSM, the LSB of each octet is transmitted first. However, in TETRA, the PDUs are packed such that 
the MSB of each octet is transmitted first as indicated in tables 29.34, 29.36 and 29.38. 

An 8-bit character number a is represented as shown in table 29.35. 

Table 29.35: 8-bit character presentation 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


aa 


ab 


ac 


ad 


ae 


at 


ag 


ah 



An 8-bit character number a has bit "a" as the most significant bit "b8" and bit "h" as the least significant bit "bl". 

The 8-bit characters shall be set into the user data information element as shown in table 29.36 for the case of four 8-bit 
characters. 

Table 29.36: Character packing for 8-bit alphabet 





Octet 1 


Octet 2 


Bit position 


n 


n-1 


n-2 


n-3 


n-4 


n-5 


n-6 


n-7 


n-8 


n-9 


n-10 


n-11 


n-1 2 


n-1 3 


n-1 4 


n-15 


Character bit 


la 


lb 


1c 


Id 


1e 


If 


ig 


1h 


2a 


2b 


2c 


2d 


2e 


2f 


2g 


2h 




Octet 3 


Octet 4 


Bit position 


n-16 


n-1 7 


n-1 8 


n-1 9 


n-20 


n-21 


n-22 


n-23 


n-24 


n-25 


n-26 


n-27 


n-28 


n-29 


n-30 


n-31 


Character bit 


3a 


3b 


3c 


3d 


3e 


3f 


3g 


3h 


4a 


4b 


4c 


4d 


4e 


4f 


4g 


4h 



A 16-bit character number a is represented as shown in table 29.37. 

Table 29.37: 16-bit character presentation 



b16 


b15 


b14 


b13 


b12 


b11 


bio 


b9 


b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


aa 


ab 


ac 


ad 


ae 


af 


ag 


ah 


ai 


aj 


al< 


al 


am 


an 


ao 


ap 



A 16-bit character number a has bit "a" as the most significant bit "bl6" and bit "p" as the least significant bit "bl". 

The 16-bit characters shall be set into the user data information element as shown in table 29.38 for the case of two 
16-bit characters. 

Table 29.38: Character packing for 16-bit alphabet 





Octet 1 


Octet 2 


Bit position 


n 


n-1 


n-2 


n-3 


n-4 


n-5 


n-6 


n-7 


n-8 


n-9 


n-10 


n-11 


n-1 2 


n-1 3 


n-1 4 


n-15 


Character bit 


la 


lb 


1c 


Id 


1e 


If 


ig 


1h 


1i 


1i 


1l< 


11 


1m 


In 


1o 


1p 




Octet 3 


Octet 4 


Bit position 


n-16 


n-1 7 


n-1 8 


n-1 9 


n-20 


n-21 


n-22 


n-23 


n-24 


n-25 


n-26 


n-27 


n-28 


n-29 


n-30 


n-31 


Character bit 


2a 


2b 


2c 


2d 


2e 


2f 


2g 


2h 


2i 


2j 


2I< 


21 


2m 


2n 


2o 


2p 
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29.5.4.3 7-bit alphabet table 

The 7-bit alphabet shall be exactly the same as that specified by the GSM standard. This alphabet should be supported 
by all MSs which support the SDS-TL protocol. Additional alphabets (including UCS2) may also be supported as 
options. 

The 7-bit alphabet shall be as shown in table 29.39. 

Table 29.39: Alphabet table for GSM 7-bit alphabet 











b7 














1 


1 


1 


1 




b6 








1 


1 








1 


1 




b5 





1 





1 





1 





1 


b4 


b3 


b2 


b1 







1 


2 


3 


4 


5 


6 


7 

















@ 


A 


SP 





i 


P 


6 


P 













1 


£ 




! 


1 


A 


Q 


a 


q 








1 





2 


$ 


d" 


" 


2 


B 


R 


b 


r 








1 




3 


¥ 


r 


# 


3 


C 


S 


c 


s 





1 








4 


e 


A 


n 


4 


D 


T 


d 


t 





1 







5 


e 


n 


% 


5 


E 


U 


e 


u 





1 


1 





6 


u 


n 


and 


6 


F 


V 


f 


V 





1 


1 




7 


1 


"¥ 


• 


7 


G 


w 


g 


w 













8 


6 


2 


( 


8 


H 


X 


h 


X 












9 


Q 





) 


9 


1 


Y 


i 


y 







1 





10 


LF 


H 


* 




J 


z 


j 


z 







1 




11 





1) 


+ 


5 


K 


A 


k 


a 




1 








12 





/E 


, 


< 


L 





1 


6 




1 







13 


CR 


ae 


- 


= 


M 


N 


m 


n 




1 


1 





14 


A 


(3 




> 


N 


U 


n 


u 




1 


1 




15 


a 


E 


/ 


? 





§ 





a 



The following rules shall apply to the use of this alphabet: 

• Control characters shall have the following meaning: 

Code Meaning 

LF Line Feed: Any characters following LF which are to be displayed shall be presented as the next line 
of the text message, commencing with the first character position; 

CR Carriage Return: Any characters following CR which are to be displayed shall be presented as the 
current line of the text message, commencing with the first character position; 

SP Space Character. 

• If these characters are to be displayed within a message, each character shall be taken in turn and be placed in 
the next available space from left to right and from top to bottom. 
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29.5.4.4 Time stamp 

The Time stamp information element shall indicates as defined in table 29.40 the (approximate) creation time of the 
message. The information element is added to a message by the SwMI to allow the destination to evaluate the age of the 
message. 

Table 29.40: Time stamp information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Reserved 


4 




M 


See note 


Month 


4 




M 


1 to 12 


Day 


5 




M 


1 to 31 


Hour 


5 




M 


0to23 


Minute 


6 




M 


0to59 


NOTE: This field is inserted to ensure that the following information elements are aligned to octet 
boundaries and so ease processing by the application. In the present document the field 
shall be set to "OOOOg". 



29.5.4.5 Timestamp used 

The Timestamp used information element shall indicate as defined in table 29.41 if a timestamp is used in the PDU. 
Table 29.41 : Timestamp used information element contents 



Information element 


Length 


Value 


Remark 


Timestamp used 


1 


02 


Timestamp not present 


12 


Timestamp present 



29.5.5 Simple location system 

The simple location system protocol is intended to be a location system application, which does not require any 
transport mechanism to ensure delivery. 

29.5.5.1 Protocol sequences 

Simple location system does not use any end-to-end acknowledgement (reporting) signalling. The only delivery 
mechanisms offered is the layer 2 acknowledge. 

29.5.5.2 PDU description tables 

Simple location system does not use the SDS-TL data transfer service PDUs, but defines a protocol specific field to 
specify the data format, refer to clause 29.5.7. The basic SDS type-4 information element shall contain elements as 
defined in clause 29.5.5.3. 

29.5.5.3 Simple location system PDU 

• Response to: 

• Response expected: 

• Short description: This PDU shall be used to send location system SDS data. 

Table 29.42: Simple location system PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Protocol identifier 


8 


1 


M 


Value 00000011 2 


Location system coding scheme 


8 


1 


M 


As defined in table 29.44 


Location system data 


variable 


1 


M 
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29.5.6 Location system using SDS-TL data transfer services 

This location system protocol set offers end-to-end acknowledgement and/or store and forward in the SwMI. 

29.5.6.1 Protocol sequences 

The protocol sequences of location system messaging shall be the protocol sequences defined in clause 29.3.3. 

29.5.6.2 PDU description tables 

The location system protocol uses the full TL protocol. Additional information elements are present in the 
SDS-TRANSFER PDU. 

29.5.6.3 Location system transfer SDU 

The location system message transfer is done by use of an SDS-TRANSFER with additional information elements 
embedded in the user data portion of the SDS-TRANSFER. The location system SDU shall be encoded as defined in 
table 29.43. 

Table 29.43: Location system SDU contents 



Information element 


Length 


Type 


C/O/IVI 


Remark 


Location system coding scheme 


8 


1 


M 


As defined in table 29.44 


Location system data 


variable 


1 


M 





29.5.7 Location system coding scineme 

For protocols carrying location system data, the location system coding scheme information element shall se as defined 
in table 29.44. 

Table 29.44: Location system coding scheme information element contents 



Information element 


Length 


Value 


Remark 


Location system coding scheme 


8 


OOOOOOOO2 


National Marine Electronics Association, see annex L 


00000001 2 


RTCIVI SC-104, see annex L 


0000001 O2 to 

011111112 


Reserved 


100000002to 

111111102 


Available for user application definition, (see note) 






111111112 


Reserved 


NOTE: Identities of these applications should be allocated by a central body in order to support interoperability. 



NOTE 1: This list only defines a subset of the available data coding schemes for location systems. The list should 
be expected to expand as more data coding schemes are adopted. 

NOTE 2: TETRA defines a standardized location information transport protocol (LIP) that uses another protocol 

identifier than the "simple location system" or the "location system", refer to clauses 29.4.3.9, 29.5.12 and 
TS 100 392-18-1 [19]. 
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29.5.8 Wireless Application Protocol (WAP) 

Wireless Application Protocol (WAP) is a result of continuous work to define an industry wide standard for developing 
applications over wireless communication networks. The scope for the WAP working group is to define a set of 
standards to be used by service applications, refer to RFC 1994 [34]. The upper layers of WAP will be independent of 
the underlying wireless network, while the data link layer might be adapted to specific features of underlying bearers. 
However, by keeping the data link layer interface, as well as the basic features, consistent global interoperability can be 
achieved using mediating gateways. 

29.5.8.1 Protocol sequences 

WAP need not use the SDS-TL data transfer services as those will only add overhead over the normal WAP operation. 
For WAP protocol sequences, the reader is referred to WAP 2.0 [i.9]. 

29.5.8.2 PDU description tables 

WAP need not use the SDS-TL data transfer service PDUs as those will only add overhead, refer to clause 29.5.1.2. The 
minimum standardized information element of WAP is the Protocol Identifier. For all other aspects of WAP the reader 
is referred to WAP 2.0 [i.9]. 

29.5.9 Message with user data header (UDH) 

The UDH protocol is based on (TP-UD) field defined in GSM specification for SMS (TS 123 040 [2]). This protocol is 
terminated in the application layer and uses SDS-TL transport service. The UDH is carried with the User Data 
parameter of the SDS-TRANSFER PDU as defined in table 29.14. 

NOTE: "Field" in GSM specifications means same as "information element" in the present document. 

29.5.9.1 Protocol sequences 

The protocol sequences of UDH messaging shall be the unmodified protocol sequences defined in clause 29.3.3. 

29.5.9.2 PDU description tables 

The UDH protocol uses the full SDS-TL data transport service protocol. The UDH protocol defines additional 
information elements, which are transported in the SDS-TRANSFER PDU. 



ETSI 



1080 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



29.5.9.3 



User Data Header transfer SDL) 



The text message transfer is done by use of an SDS -TRANSFER PDU with additional information elements embedded 
in the user data portion of the SDS-TRANSFER PDU. The SDU part as defined in table 29.45 shall be the user data in 
the SDS-TRANSFER PDU, refer to table 29.14. 

Table 29.45: UDH transfer SDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Time stamp used 


1 


1 


M 


As defined in table 29.41 , see 
note 1 . 


Text coding sclieme 


7 


1 


M 


As defined in table 29.29, see 
note 1 . 


Time stamp 


24 




C 


As defined in table 29.40, see 
note 2. 


User Data Header length 


8 


1 


M 


See note 3. 


User Data Header information 
element 


Variable 




C 


Repeatable, see note 4. 


Network layer user data 


Variable 




C 


See note 5. 


NOTE 1 : These two elements can be processed together in order to keep byte alignment. 

NOTE 2: This information element shall be present only, when the Time stamp used indicates the presence 

of timestamp. 
NOTE 3: The User Data Header length information element shall indicate the number of octets within the 

User Data Header information element information elements, which follow and shall not include 

itself in its count. 
NOTE 4: The User Data Header length indirectly defined how many User Data Header information element 

information elements are present as each User Data Header information element contains its 

length. 
NOTE 5: The Network layer user data information element may be present and the content depends on 

UDH information element ID meaning. The end of the Network layer user data information 

element is defined by the end of the SDS-TRANSFER PDU. 



29.5.9.4 



UDH transfer SDU information elements 



29.5.9.4.1 User Data Header Information Element 

The User Data Header information element information element shall be encoded as defined in table 29.46. 
Table 29.46: User Data Header information element information element contents 



UDH information element ID (1) 


8 


1 


M 


See note 1 . 


UDH information element length (1) 


8 


1 


M 


See note 2. 


UDH information element data (1) 


Variable 




C 


See note 3. 


N0TE1: See table 29.47. 

NOTE 2: The UDH information element length information element shall indicate the number of octets 

within its associated UDH information element data information element, which follows and shall 

not include itself in its count value. 
NOTE 3: The content depends on UDH information element ID meaning. 
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The UDH information element ID information element shall be encoded as presented in table 29.47. 
Table 29.47: UDH information element ID information element contents 



Information element 


Length 


Value 


Remark 


Clause 


UDH information element ID 


8 


OOOOOOOO2 


Concatenated text message (8-Bit reference 
number) 


29.5.10 


00000001 2 to 
000001 II2 


Reserved (see note) 


- 


00001 OOO2 


Concatenated text message (16-Bit reference 
number) 


29.5.10 


00001 001 2 to 

111111112 


Reserved (see note) 


- 


NOTE: Defined in GSM specification for SMS (TS 1 23 040 [2]). | 



29.5.1 Concatenated text messaging 

Concatenated text messaging uses the UDH protocol. It allows an application to concatenate several single SDS text 
messages to transfer one long text message. Each single message is a segment of the long text message. Segmentation 
and recombination of long text messages is done in the application layer. 

29.5.10.1 Protocol sequences 

The protocol sequences of concatenated text messaging shall be the unmodified protocol sequences defined in 
clause 29.3.3. 

29.5.1 0.2 PDU description tables 

The UDH protocol uses the full SDS-TL data transport service protocol. The UDH protocol defines additional 
information elements, which are transported in the SDS-TRANSFER PDU. 

29.5.1 0.3 Concatenated text message transfer SDU 

The concatenated text message transfer is done by use of an SDS-TRANSFER PDU with additional information 
elements embedded in the user data portion of the SDS-TRANSFER PDU. The SDU part as defined in table 29.48 shall 
be the user data in the SDS-TRANSFER PDU, refer to table 29.46. 

NOTE: In the table 29.48 the User Data Header information element as defined in table 29.46 is presented as 
information elements of the Concatenated text message transfer SDU. 

Table 29.48: Concatenated text message transfer SDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Time stamp used 


1 




M 


As defined in table 29.41 (see note 1) 


Text coding scheme 


7 




M 


As defined in table 29.29 (see note 1) 


Time stamp 


24 




C 


As defined in table 29.40 (see note 2) 


User Data Header length 


8 




M 




UDH information element ID 


8 




M 




UDH information element length 


8 




M 




Message reference number 


8/16 




C 


(see note 3) 


Maximum number of messages 


8 




M 




Sequence number of current message 


8 




M 




User text (Text segment) 


Variable 




M 


(see note 4) 


NOTE 1 : These two elements can be processed together in order to keep byte alignment. 

NOTE 2: This information element shall be present only, when the Time stamp used indicates the presence of 

timestamp. 
NOTE 3: The length and value depends on the UDH information element ID see table 29.47 and clause 29.5.1 1 .7. 
NOTE 4: The length of the User text is determined by the end of the User data in the SDS-TRANSFER PDU. 
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29.5.1 0.4 Concatenated text message short form acknowledgement 

The concatenated text messaging may use the SDS-SHORT REPORT PDU as defined in clause 29.4.4.4. 

The destination MS/LS can choose between the SDS-SHORT REPORT PDU and the SDS-REPORT PDU in the cases 
where the report types available in the short form will suffice, refer to clause 29.3.3.4.4. 

29.5.1 1 Concatenated text messaging information elements 

29.5.11.1 Text coding scheme 

See clause 29.5.4.1. 

29.5.11.2 Time stamp 

See clause 29.5.4.4. 

29.5.11.3 Time stamp used 

See clause 29.5.4.5. 

29.5.11.4 User data header length 

See clause 29.5.9.3. 

29.5.1 1 .5 UDH information element ID 

The value shall be "Concatenated SDS text message (8 bit reference number)" or "Concatenated SDS text message (16 
bit reference number) "as defined in table 29.47. 

29.5.1 1 .6 UDH information element length 

The value depends on the UDH information element ID. If the UDH information element ID is "Concatenated Text 
Message (8 bit reference number)" the value is 3 bytes. If the UDH information element ID is "Concatenated Text 
Message (16 bit reference number)" the value is 4 bytes. 

29.5.1 1 .7 Message reference number 

The length depends on UDH information element ID. It shall contain modulo 256 counter for 8 bit length or 
modulo 65 536 for 16 bit indicating the reference number for a particular concatenated short message. This reference 
number shall remain constant for every short message, which makes up a particular concatenated short message. 

29.5.1 1 .8 Maximum number of messages 

Maximum number of SDS text messages in the concatenated SDS text message. This octet shall contain a value in the 
range to 255 indicating the total number of SDS text messages within the concatenated SDS text message. The value 
shall start at 1 and remain constant for every SDS text message, which makes up the concatenated SDS text message. If 
the value is zero then the receiving entity shall ignore the whole UDH information element. 

29.5.1 1 .9 Sequence number of current message 

The Sequence number of current message shall contain a value in the range to 255 indicating the sequence number of 
a particular SDS text message within the concatenated SDS text message. The value shall start at 1 and increment by 
one for every SDS text message sent within the concatenated SDS text message. If the value is zero or the value is 
greater than the value in octet 2 then the receiving entity shall ignore the whole UDH information element. 
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29.5.11.10 User text (Text segment) 

The sender application is responsible for dividing a text message into a concatenated SDS text message. The receiver 
application is responsible for re-constructing the concatenated SDS text message. 

29.5.12 Location information transport 

29.5.12.1 General 

The Location Information Protocol (LIP) is defined in TS 100 392-18-1 [19] and clauses 29.5.9.2 to 29.5.9.6 define 
how SDS-TL shall be used as a transportation mechanism for it. The location information protocol is described as an 
application using SDS-TL service at SDS-TL SAP, refer to 29.1.1. The location information protocol can use packet 
data at SNDCP SAP as defined in clause 28. The use of packet data is outside the scope of the clauses 29.5.12.2 to 
29.5.12.6 of the present document. 

29.5.1 2.2 Protocol sequences at SDS-TL 

The location information protocol does not use any end-to-end acknowledgement (reporting) signalling of the SDS-TL 
protocol. The only delivery mechanisms at the transportation level is the layer 2 acknowledgement. 

29.5.12.3 Location information protocol architecture 

29.5.12.3.1 System architecture 

System architecture is described in TS 100 392-18-1 [19]. 



29.5.12.3.2 



MS architecture 



When the location information protocol (LIP) uses SDS-TL data transfer service figure 29.9 shows the position of the 
location information transport protocol in the MS/LS protocol stack. The physical location of the location transport 
protocol and LIP-SAP may be imbedding into the user applications and is outside the scope of the present document. A 
physical access to the LIP-SAP is outside the scope of the present document. 



User applications 



LIP-SAP 



Location information 
protocol 



SDS-TL-SAP 




TNSDS-SAP 



Figure 29.9: LIP position in TETRA protocol stack 

Location information protocol adds a layer of protocol functionality that utilizes the SDS-TL. 

The location information protocol can use services of the TNSDS-SAP via SDS-TL-SAP. The location information 
protocol shall run parallel to any other protocols utilizing SDS-TL without any interactions. 
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29.5.1 2.4 Addressing at SDS-TL 

The addressing for the LIP shall use the basic SDS addressing without store and forward addresses. 

29.5.12.5 Location information transport protocol 

TS 100 392-18-1 [19] defines the location information protocol. 

29.5.1 2.6 SDS-TL overhead 

The location information transport PDUs in the LIP shall use a PID value that is not utilizing SDS-TL transport service. 
The general content of the SDS type 4 user data part shall be as shown in table 29.49. 

Table 29.49: SDS type 4 user data contents for LIP protocol 



Information element 


Length 


Type 


C/O/M 


Value 


Remark 


Protocol identifier 


8 


1 


M 




Location information protocol 


Location information transport 
protocol PDU 


variable 


1 


M 




See note. 


NOTE: Content of this information element is defined in TS 1 00 392-1 8-1 [1 9]. 



29.5.1 3 Net assist protocol 

29.5.13.1 General 

The Net Assist Protocol (NAP) is defined in TS 100 392-18-2 [20] and clauses 29.5.9.2 to 29.5.9.6 define how SDS-TL 
shall be used as a transportation mechanism for it. The Net Assist Protocol is described as an application using SDS-TL 
service at SDS-TL SAP, refer to clause 29.1.1. 

29.5.1 3.2 Protocol sequences at SDS-TL 

The location information protocol does not use any end-to-end acknowledgement (reporting) signalling of the SDS-TL 
protocol. The only delivery mechanisms at the transportation level is the layer 2 acknowledgement. 

29.5.13.3 Location information protocol architecture 
29.5.13.3.1 System architecture 

System architecture is described in TS 100 392-18-2 [20]. 
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29.5.13.3.2 



MS architecture 



When the Net Assist Protocol (NAP) uses SDS-TL data transfer service figure 29.10 shows the position of the location 
information transport protocol in the MS/LS protocol stack. The physical location of the location transport protocol and 
NAP-SAP may be imbedding into the user applications and is outside the scope of the present document. A physical 
access to the NAP-SAP is outside the scope of the present document. 

User applications 



CMCE i 



CC 



t 



NAP-SAP 



Net assist protocol 



t 



SDS-TL-SAP 



SDS-TL 



TNSDS-SAP 



SS 



t 



SDS 



Figure 29.10: NAP position in TETRA protocol stacl< 

The Net Assist Protocol adds a layer of protocol functionality that utilizes the SDS-TL. 

The Net Assist Protocol can use services of the TNSDS-SAP via SDS-TL-SAP. The Net Assist Protocol shall run 
parallel to any other protocols utilizing SDS-TL without any interactions. 

29.5.1 3.4 Addressing at SDS-TL 

The addressing for the Net Assist Protocol shall use the basic SDS addressing without store and forward addresses. 

29.5. 1 3.5 Net Assist Protocol 

TS 100 392-18-2 [20] defines the Net Assist Protocol. 

29.5.13.6 SDS-TL overhead 

The Net Assist Protocol PDUs in the NAP shall use a PID value that is not utilizing SDS-TL transport service. The 
general content of the SDS type 4 user data part shall be as shown in table 29.50. 

Table 29.50: SDS type 4 user data contents for NAP protocol 



Information element 


Length 


Type 


C/O/M 


Value 


Remark 


Protocol identifier 


8 


1 


M 




Net Assist Protocol 


Net assist protocol PDU 


variable 


1 


M 




See note. 


NOTE: Content of this information element shall be as defined in TS 1 00 392-1 8-2 [20]. 
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30 Multimedia Exchange Layer 
30.1 General 

Clause 30 describes the structure and the functionality of the TETRA Multimedia Exchange (MEX) Layer. The TETRA 
MEX layer resides above the SNDCP defined in clause 28. 

The MEX layer supports the Internet Protocol (IP) and at the MS side the IP and the higher layers on top of it may be 
located at the MT and the TE. Support of the full MEX layer functionality is optional. 

Figure 30. 1 illustrates the usage of TETRA MEX layer with the applications in MT. 
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Figure 30.1 : Usage of TETRA packet data with IVIEX Layer witli an IVITO application 

Figure 30.2 illustrates the usage of TETRA packet data with the MEX layer when the application uses IP protocol. 
Applications are illustrated with co-existence within both the TE2 and MT2 allowing them to independently access 
TETRA packet data services and associated QoS management. 
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Figure 30.2: Usage of TETRA pacltet data with) IVIEX for TE2 and MT2 IP applications 
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The IP traffic fi-om the TE and MT applications go through the MEX layer. The MEX layer handles three types of IP 
traffic: 

Type 1 - Control traffic between the applications and the MEX layer. 

Type 2 - Data traffic between the applications and the SNDCP layer via the MEX layer. 

Type 3 - Data traffic between the applications and the SNDCP layer (bypassing the MEX layer). 

In addition, the MEX layer handles the communication with the SNDCP layer using the SNDCP primitives, which will 
be discussed as part of this clause in the later sections. First, the details of the MEX layer interface will be described. 

Figure 30.3 illustrates a typical deployment example showing the full set of components involved, namely: 

• PEI Ctrl/Phy - The peripheral equipment interface. 

• PCON - A logical connection associated with the PEI physical connection. Where a modern high speed 
connectivity technology is implemented, several logical PCONs may be available. In a legacy implementation 
only one PCON is available utilizing a V.24/V.28 physical interface. 

• DLL (PEI) - The link layer protocol for carrying data across the Peripheral Equipment Interface (PEI). Most 
commonly. Point to point protocol (PPP) is employed. 

• NCON - A network connection consisting of an IP address. Subnet mask. Gateway address and other 
applicable parameters for support of carrying IP packets to and from the MT2. Where multiple PDP contexts 
are supported, both the TE2 and internal application environment of the MT2 can host multiple NCONs and 
hence, multiple IP addresses. An NCON can typically be a connected PPP connection over a PCON. 

• IP - The section of the IP stack related to an applicable NCON. 

• Applications - Applications requiring both uplink and downlink packet data services. 

• QoS Manager - An agent which often resides close to the IP stack which can negotiate QoS services and 
capabilities in IP networks. In TETRA, the QoS Manager may use either AT commands or TNPl protocol to 
negotiate QoS enabled packet data services. Applications, themselves, may also implement QoS management 
functionality. 
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Figure 30.3: MEX Peripheral Interfaces 
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Access to MEX services is available via 2 possible SAPs: 

• TNMXPI SAP - Service Access Point to carry data and configuration via the Peripheral Equipment Interface 
(PEI). For clarity, the PEI section of Figure 30.3 illustrates multiple logical PEI connections (PCON) over 
which applications may communicate through TNMXPI. Note that applications may have either a dedicated 
PCON or may share a PCON (PCONn). Furthermore, these relations, by definition, bear no specific mapping 
to a particular context at the SNDCP. 

• TNMXIT_SAP - Service Access Point to carry data and configuration related to applications housed internally 
to the MT. 

The MEX layer incorporates the following functionality some of which is mandatory or optional as denoted by (M) or 
(O): 

• QoS Filter (M) - To assist in routing of application data having different QoS requirements to appropriately 
predefined PDP contexts. 

• Precedence Buffer (O) - To manage flow of IP packets to SNDCP according to precedence requirements. 

• Context/QoS Management (M)- To provide an abstracted interface to PDP context creation and modification, 
QoS negotiation and Uplink data routing via the QoS Filter. 

Each application using the MEX layer transfers data through the IP transport layers via NCONs. The application or 
associated QoS Manager on the MS must request its QoS via the MEX-CONNECT primitive together with the QoS 
filter information. Upon success, a PDP context exists and the MEX and SwMI are prepared to route data with the 
appropriate QoS on both the uplink and downlink. 

MEX supports three forms of QoS filtering: 

1) Port Filtering - The MEX inspects the destination port and protocol (port type) fields of the uplink IP transport 
packet header and ensures that the packet is routed via SNDCP SN-DATA primitive to the NSAPI with the 
previously accepted QoS. The use of a port filter requires that the application is using a port oriented transport 
protocol (e.g. UDP, TCP, SCTP, and DCCP). 

2) Port and Peer IP Address Filtering - The destination IP Address is inspected in addition to the destination port 
and protocol fields of the uplink IP transport packet header and ensures that the packet is routed via SNDCP 
SN-DATA primitive to the NSAPI with the previously accepted QoS. This method allows differentiation of 
QoS for similar applications residing on different peer nodes in the packet network. 

3) Diffserv - The lower 5 bits (4 to 0) of the 6 bit Differentiated services Code Point (DSCP) is inspected in the 
IP packet header and ensures that the packet is routed via SNDCP SN-DATA primitive to the NSAPI with the 
previously accepted QoS. The application should appropriately utilize the "Per Hop Behaviour (PHB)" classes 
which are defined by RFC 2474 [43], RFC 2475 [44], RFC 2597 [45] and RFC 2598 [46]. Bit 5 of DSCP is 
used to allow the application to utilize the escalated priority functionality which is defined within the MEX. 

MEX itself can perform QoS filtering only on the uplink. However, interfaces are provided to allow requests to be 
forwarded via SNDCP in order to set QoS filtering at the SwMI to facilitate filtering on the downlink also. 

Four QoS filter transaction types are defined: 

1) Uplink Filter - The application on the MS sends IP packets to a peer on the IP network. IP packets are routed 
to PDP context on the Uplink by the MEX QoS filter based upon either: 

the destination port and protocol field; 

destination port and protocol field plus destination IP address; or 

DSCP of the transmitted IP transport packets. 
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2) Downlink Filter - The application on the MS awaits receipt of IP packets on the downlink from the IP 
network. Downlink IP transport packets may be routed to PDP context at the SwMI based upon either: 

the destination port and protocol field; 

destination port and protocol field plus source IP address; or 

DSCP of the IP packet. 

3) Downlink Automatic Filter - The application on the MS sends IP packets to a peer on the IP network. Uplink 
IP packets are routed to PDP context on the uplink by the MEX QoS Filter based upon either: 

destination port and protocol field; 

destination port and protocol field plus destination IP address; or 

DSCP of the IP packet. 

Either the: 

■ source port and protocol field; 

■ source port and protocol field plus destination IP; or 

DSCP of the uplink IP packet 

may be recorded at the SwMI to allow for automatic downlink filtering. Automatic filtering at the SwMI on the 
downlink may use the recorded information to filter downlink packets by either: 

■ destination port and protocol field; 

■ destination port and protocol field plus source IP address; or 

■ DSCP to the appropriate PDP context. 

4) Uplink Automatic Filter - The application on the MS awaits receipt of IP transport packets on the downlink 
from the IP network. Downlink IP transport packets are routed to PDP context at the SwMI based upon either 

destination port and protocol field; 

destination port and protocol field plus source address; or 

DSCP of the IP packet. 

Either the: 

■ source port and protocol field; 

■ source port and protocol field plus source IP address; or 

DSCP of the downlink IP packet 

is recorded at the MEX QoS Filter to allow for automatic uplink filtering. Automatic filtering at the MEX QoS 
Filter uses recorded information to filter uplink packets by: 

■ destination port and protocol field; 

■ destination port and protocol field plus destination IP address; or 
DSCP. 

Automatic filters are defined to support the client/server connection oriented nature of the IP protocol. 

Where multiple filters are specified, there may be the occasion where an Uplink or Downlink Filter may conflict with a 
filter automatically determined by an automatic filter. In this state, the explicitly defined Uplink or Downlink filter shall 
take precedence and override that automatically defined filter. 

The usage of DSCP is outside the scope of the present document. 
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The method of transferring peer IP address or Diffserv QoS Filter information to the SwMI for the purpose of downlink 
filtering is outside the scope of the present document. Therefore QoS Filtering including the peer IP address or Diffserv 
may be only supported on the uplink. 

30.2 MEX Layer Overview 

30.2.1 General 

MEX is a TETRA specific network layer with the primary objective to provide a simplified interface to allow the 
development of applications which can take advantage of the advanced QoS capabilities made available by the packet 
data service of TETRA. 

MEX can offer 3 levels of abstraction to the application or QoS Manager with respect to the negotiation of QoS. 

1) Legacy context - An application initiates a packet data transfer (equivalent to ATD*99#). The MEX initiates 
creation of a PDP context via SNDCP using a default set of QoS settings (see clause 3.2.2.4; MEX QoS Class 
entry 0). 

2) MEX QoS - An application or QoS Manager initiates creation of a PDP context by specifying a range of QoS 
by specifying 2 of 256 QoS abstract classes; one indicating an upper QoS requirement and one indicating a 
lower QoS requirement and a QoS filter specification. The MEX then automates the creation of the PDP 
context, and negotiates the QoS within the specified limits. The full range of QoS classes and attributes 
together with MEX QoS filtering on the uplink is available in this mode. 

3) SNDCP QoS - An application or QoS Manager may initiate direct creation of a PDP context and data transfer 
using the full SNDCP QoS primitives. Automatic negotiation using MEX QoS class, MEX Precedence, MEX 
QoS filtering on the uplink are not supported in this mode. 

Applications residing on both TE2 and MT2 the can utilize any of the three options above and can coexist at any time, 
limited only by the services available at the SNDCP. 

30.2.2 QoS Classes 
30.2.2.1 Data Class 

Each TE2 and MT2 application that requires access to the MEX layer can belong to one of three classes. MEX layer 
offers QoS to the following multimedia service classes: 

Real-time class layer 2 link optimized for data which cannot tolerate delivery delay (late packets discarded by 
the receiving application); 

Telemetry class layer 2 link optimized for intermittent data which can tolerate moderate delivery delay and 
packet loss; 

Background class layer 2 link optimized for data which are intolerant of packet loss. 

Real-time class applications require regular access to the radio resources, and have low delay tolerance. Although data 
reliability is important for such applications, it can be compromised for low transmission delays. Typical examples of 
applications which would utilize this class are video conferencing and packet speech transmission. 

The telemetry class applications may also require regular access to the radio resources, and have moderate delay 
tolerance (higher than real-time class). Reliability can be compromised for short transmission delays. Depending on the 
update rate of the application data, even unacknowledged transmission may be used. Typical examples include location 
update, medical telemetry and data logging applications. 

The background class is the most delay tolerant among all the multimedia classes. In most cases, the objective is to 
transmit the packets correctly despite long delays. Although high data throughput is a desirable feature, its absence does 
not dramatically affect the usability of the application. Web browsing, file transmission and control applications belong 
to this class. 
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30.2.2.2 Delay Class 

Maximum packet delay refers to the delay within a single SwMI TETRA network from MS to MS. 

The reader should refer to clause 28.2.3.2 for details of achievable maximum packets delays for each of the delay 

Classes: 

• Low; 

• Moderate; 

• High; and 

• Unpredicatable. 

30.2.2.3 Reliability Class 

Packet reliability is specified for the local MS - SwMI air interface for a single link and it is not associated with the 
end-to-end reliability. 

The reader should refer to clause 28.2.3.2 for details of N-PDU reliability for each of the reliability classes: 

• High; 

• Moderate; and 

• Low. 



30.2.2.4 



MEX QoS abstract class 



The MEX QoS Abstract class is defined for the ease of setting the multitude of QoS parameters by the application. The 
MEX shall implement a table (MEX_QOS_CLASS_TBL) of up to 256 MEX QOS abstract classes which can be chosen 
or modified by the TE2 application via MEX-QOSCLASS. A default QoS class is used to support legacy applications 
which do not request any QoS via the PEL MEX QoS Classes 0-8 are defined in this specification and shall be 
implemented in all MT2. These are shown in table 30.3 MEX QoS Classess 9 to 32 are researved for addition of 
manufactuer specific values. For entries in MEX_QOS_CLASS_TBL which are accessible for modification (33 to 255), 
a lock feature is available to prevent applications from modifying each others' entries in the MEX_QOS_CLASS_TBL. 

Two entries in the MEX QoS Class table can be used to define a range of acceptable QoS during MEX-CONNECT to 
allow MEX the flexibility to automatically negotiate QoS with SNDCP and, hence, the network. Where a range (Upper 
and Lower) is used the following table 30.2 clarifies the upper and lower values for each QoS Class / Parameter. 

Table 30.2: Full Range of operation for QoS Classes and Attributes 



Class / Attribute 


Upper 


Lower 


Note 


Minimum Peal< Throughput 


> 64 000 


<1000 


Octets/s 


IVIean Throughout 


Best effort 


100 


Octets/h 


IVIean Active Throughput 


Best effort 


100 


Octets/h 


Data Class 


Real time 


Background 




Delay Class 


High 


Unpredictable 




Reliability Class 


High 


Low 




CONTEXT_READYtime 


300 s 


200 ms 


Where track READY timer is required, this 
should be entered for both upper and lower 


Scheduled Repetition Period 


706 


4 


Slot durations (85/6ms) 


Scheduled Timing Error 


1 


128 


Slot durations (85/6ms) 


Scheduled Number of N-PDUs per grant 


7 


1 




Scheduled N-PDU size 


2002 


1 


Octets 


IVIEX Precedence 


14 


1 




MEX Data Priority 


7 







MEX PDU Priority Max 


7 







MEX Data Importance 


High 


Low 
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Applications which do not have a preference for a particular class or parameter should specify the extreme range as 
given in the table 30.5. Applications which have a direct need should specify the specific range as tightly as appropriate 
for the specifc requirement or specify identical values in both the upper and lower request. 
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Table 30.3: Fixed values for MEX QoS Class 





MEX QoS Class 




QoS parameter 


(default) 


1 


2 


3 


4 


5 


6 


7 


8 


Remarks 


Minimum peak 
tfiroughput 


<1 000 


<1 000 


<1 000 


>1 000 


>2 000 


>4 000 


>1 000 


>8 000 


> 32 000 


Octets/s 


Mean throughput 


Best effort 


100 000 


10 000 


500 000 


2 000 000 


10 000 000 


Best effort 


Best effort 


Best effort 


Octets/h 


Mean active throughput 


<1 000 


<1 000 


<1 000 


>1 000 


>2 000 


>4 000 


50 000 000 


50 000 000 


50 000 000 


Octets/h 


Data class 


Beackground 


Background 


Bactground 


Telemetry 


Telemetry 


Telemetry 


Real time 


Real time 


Real time 




Delay class 


Unpredictable 


Unpredictable 


Unpredictable 


Low 


Moderate 


High 


Low (default) 


Low (default) 


Low (default) 


Unpredictable, 
High, Moderate, 
Low 


Reliability class 


Moderate 


Moderate 


High 


High 


Moderate 


Low 


Low (default) 


Low (default) 


Low (default) 


High, Moderate, 
Low 


CONTEXT READY time 


track READY 


track READY 


track READY 


500 ms 


1 s 


2s 


3s 


2s 


500 ms 




Schedule repetition time 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


20 


50 


70 


150 


100 


20 


4 to 706 slot 
durations (85/6 ms) 


Schelude timing error 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


2 


5 


10 


3 


2 


1 


<1 to < 128 slot 
durations 


Scheduled number of 
N-PDUs per grant 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


1 


1 


1 


5 


6 


7 


1 to 7 N-PDUs per 
grant 


Scheduled N-PDU size 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


N/A 

(Background 

class) 


150 


500 


1 000 


500 


2 000 


1 300 


Octets 


MEX precedence 


1 


1 


1 


2 


2 


2 


10 


12 


14 


1 to 14 


MEX data priority 











6 


4 





6 


4 





- Low, 7 - High 


MEX PDU priority max 











6 


4 





6 


4 





- Low, 7 - High 


MEX data importance 


High 


Medium 


Low 


High 


Medium 


Low 


High 


Medium 


Low 


Low, Medium, High 
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30.2.3 QoS Attributes 

30.2.3.1 General 

In addition to the QoS classes described above, the MEX layer supports the following QoS attributes which shall be as 
defined in the clauses 30.2.3.2 to 30.2.3: 

Data throughput; 

MEX precedence; 

Data Priority; 

PDU Priority; 

Data importance; 

Scheduled access; and 

CONTEXT_READY time. 

30.2.3.2 Data Throughput 

An MT or TE application always requests the following parameters as different throughput measures: 

• Minimum Peak Throughput - The expected minimum peak throughput, measured in octets per second. This 
indicates to the lower layers how allocate channel bandwidth, coding and modulation in order to achieve the 
minimum peak throughput require by the application. This is the minimum peak throughput of N-PDUs in 
units of octets/s requested or offered for a particular PDP context. This is the minimum throughput required 
when the PDP context is at its most active; if the peak rate available is lower than this, the application may not 
be usable (though the application may be capable of using a higher rate than this). Valid values are: 

< 1 000; 

> 1 000; 

> 2 000; 

> 4 000; 

> 8 000; 

> 16 000; 

> 32 000; and 

> 64 000. 



• 



Mean Throughput - The expected mean throughput, measured in octets per hour is averaged over the 
expected lifetime of the associated PDP context. This is the mean throughput of N-PDUs expected by the 
SNDCP service user, averaged over the expected lifetime of the PDP context. It is given in units of octets per 
hour. Valid values are: 

100 (-0,22 bits/s); 

200 (-0,44 bits/s); 

500 (-1,11 bits/s); 

1 000 (-2,2 bits/s); 

2 000 (-4,4 bits/s); 
5 000 (-11,1 bits/s); 
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10 000(~22bits/s); 
20 000 (-44 bits/s); 
50 000(~lllbits/s); 
100 000 (-0,22 kbits/s); 
200 000 (-0,44 kbits/s); 
500 000 (-1,11 kbits/s); 

1 000 000 (-2,2 kbits/s); 

2 000 000 (-4,4 kbits/s); 
5 000 000 (-11,1 kbits/s); 
10 000 000 (-22 kbits/s); 
20 000 000 (-44 kbits/s); 

50 000 000 (-111 kbits/s); and 

Best effort. 

NOTE: These values follow those given for GPRS (see EN 301 344 [i.l 1]). 

• Mean Active Throughput - The mean active throughput, measured in octets per hours, is averaged over the 
period defined by the CONTEXT_READY time. Values shall be as for the Mean throughput. 

30.2.3.3 MEX Precedence 

MEX precedence defines how frequently application data is transferred to the SNDCP for transmission, which is 
achieved by a queuing mechanism at the MEX layer. The MEX layer provides data precedence internally, which can 
manage an unlimited number of applications simultaneously. Each application can choose one of 14 precedence levels 
(1 to 14). Note that if an application does not specify a precedence level, it is assigned to precedence level 1. 

The MEX precedence mechanism consists of an application list, multiple buffers and a precedence switch as shown in 
figure 30.4. MEX Precedence is a round robin mechanism which processes and transfers packets to the SNDCP as 
follows: 

• 



• 



up to 14 packets from each application which has specified precedence level 14, 
up to 13 packets from each application which has specified precedence level 13 

• and so on for each precedence level; until 

• one packet is processed for each application which has requested precedence level 1 . 

The round robin then continues again at precedence level 14. 

During PDP context activation, the application chooses the MEX precedence level using MEX-CONNECT, and the 
MEX layer places that application to its precedence list. Each precedence level is associated with an internal buffer. 
Therefore, after an application chooses its MEX precedence, its MEX-DATA payload is routed to a corresponding 
buffer. Each buffer output is connected to a precedence switch, which allocates the available MEX output bandwidth 
dynamically. In other words, high precedence data is transferred more frequently than the low precedence one. 

A precedence rank figure is defined to allow an application to understand its real placement within the precedence 
buffer where there may be other application operating for which the requesting application is not directly aware. 
Equation 1 describes how precedence rank is derived. This provides a figure relating to the ratio of full precedence 
bandwidth that the application is actually given. An application may then choose to modify its MEX Precedence or 
other QoS parameter should its actual placement not be sufficient. 
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PR 




(1) 



Y^n*NAP 



where 

PR = Precedence Rank 

RP = Requested Precedence level 

NAP = Number of applications which are operational at that precedence. 

If the MEX precedence functionality is not supported, Precedence Rank will always equal 0. 

Two examples of usage are given in order to explain the functionality offered by the MEX precedence buffer. 

EXAMPLE 1: In simple terms, application A requests precedence 14 and application B, requests precedence 7. 

Where both applications provide a sensible matched throughput to the requested MEX precedence, 
the precedence switch transfers 14 packets (MEX-DATA primitives) as SN-DATA to the SNDCP. 
Once 14 packets of application A are transferred, 7 packets of application B are then transferred. 
Application A therefore has twice the precedence of application B. A similar precedence is 
achieved using precedence 2 and 1 respectively effectively operating in a different precedence 
dimension. However, the application may wish to request an appropriate precedence dimension to 
assist in matching an equivalent Scheduled access (i.e. Scheduled N-PDUs per grant). 

Precedence Rank for both cases is therefore: 

Apphcation A - 0,667 (66,7 %); 

AppHcation B - 0,333 (33,3 %). 

EXAMPLE 2: Figure 30.4 illustrates 4 applications populating the precedence list. Where all applications provide 
a sensible matched throughput to the requested MEX precedence, the follow packet transfer 
occurs: 

14 packets of application 1 ; 

1 1 packets of application 2; 

1 1 packets of application 3; and 

1 packet of application 4. 

Precedence Rank is therefore: 

Apphcation 1 has PR=0,378 (37,8 %); 

Apphcation 2 has PR=0,297 (29,7 %); 

Apphcation 3 has PR=0,297 (29,7 %); and 

Apphcation 4 has PR=0,027 (2,7 %). 
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MEX Precedence 


Precedence List 


14 


Applicationi 


13 




12 




11 


Application 2 & 3 








2 




1 


Application 4 




Precedence 
Switch 



MEX Precedence 
OUTPUT 



Figure 30.4: MEX Precedence 



30.2.3.4 Data Priority 



Data priority allows an MS to transmit high data-priority N-PDUs (IP packets) ahead of lower data-priority N-PDUs 
from the same MS and other MSs. 8 levels of data priority are defined where is the lowest and 7 is the highest. 

30.2.3.5 PDU Priority 

PDU priority affects LLC queue reordering and the MS's permission to use random access opportunities. 8 levels of 
PDU priority are defined where is the lowest and 7 is the highest priority. 

30.2.3.6 Data Importance 

Data Importance allows the SNDCP the option to delete or cancel untransmitted lower importance N-PDUs in 
circumstances where buffer overflow might otherwise occur. Data Importance has three levels, Low, Medium and High. 

30.2.3.7 Scheduled Access Option 

Scheduled access allows the application to reserve a periodic schedule of bandwidth appropriate to the application's 
requirements. Only the real-time and telemetry service classes may request regular access from the network. 

Four attributes are defined to allow specification of the required schedule. Figure 30.5 illustrates the relationship 
between these attributes. Timing is always described with respect to the slot duration of 65/6 ms: 

• Schedule Repetition Period - the number of slot durations between each schedule grant. Valid values are 4 
(56,67 ms) to 706 (10 s). 

• Scheduled number of IP Packets (N-PDUs) per grant - Each grant can consist from 1 up to 7 IP packets. 

• Scheduled IP Packet (N-PDU) size - the size of the IP packet (N-PDU). This may be from 1 to 2002 octets and 
may be specified separately for each IP packet within the grant. 

• Schedule Timing Error - This allows the specification of a tolerated delay relative to the scheduled slot 
granting time. This is measured in slot durations and can be specified to be <= 1 to <= 128 slot durations. Note 
that the Scheduled Repetition Period is maintained and that Schedule Timing Error does not accumulate on 
each schedule grant. 
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Scheduled Number 

of IP Packets 
(N-PDUs) per Grant 



Scheduled IP Packet 
(N-PDU) Size 



Schedule Timing 
Error 



Schedule Repetition Period 



7 



Figure 30.5: Scheduled Access 



30.2.3.8 



CONTEXT READY timer 



For a PDP context, the CONTEXT_READY time is the duration for which the PDP context is actively transferring 
data. Upon the expiration of the CONTEXT_READY time the SwMI is free to reallocate resources to other active PDP 
contexts. Valid values are: 

track READY timer; 

200 ms; 

500 ms; 

700 ms; 

1 s; 

2 s; 

3 s; 
5 s; 
10 s; 
20 s; 
30 s; 
60s; 
120 s; 
180 s; and 
300 s. 



30.2.3.9 Escalated Priority 

Where an application may require to send temporary higher priority data, the MEX provides a means for the application 
to specify this. This is commonly used in the TCP header where the URG flag is utilized to indicate the highest urgency 
in transferring the packet. 

A mechanism is also provided for the application to mark escalated priority within the IP header to allow the use of 
other transport protocols such as UDP. Bit 5 of the Differentiated Services Code Point field (DSCP) is utilized 
(according to the Local Use definition given by RFC 2474 [43]). 
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The following two options are available for the application to mark a packet for escalated priority: 

• Bit 5 of DSCP in the IP Header is set; and 

• A TCP protocol is used and the URG flag is set. 

The MEX QoS Filter shall inspect the packet protocol field. If the packet protocol field is TCP then the URG flag is 
inspected. The MEX shall also inspect bit 5 of the DSCP IP Header field. 

The PDU Priority, Data Priority and Data Importance added to the SN-DATA/SN-UNITDATA primitive is derived as 
follows for each IP packet to be transmitted on the upUnk. Note that MEX_SNDATA_QOS_TBL is not affected by this 
operation: 

a) Protocol field is not TCP and DSCP bit 5 is not set - use the PDU Priority, Data priority and Data Importance 
from MEX_SNDATA_QOS_TBL. 

b) Protocol field is not TCP and DSCP bit 5 is set - increase PDU Priority and Data priority by 2 from the 
appropriate values stored in MEX_SNDATA_QOS_TBL. Increase Data Importance by one point higher over 
the value stored in MEX_SNDATA_QOS_TBL. 

c) Protocol field is TCP, DSCP bit 5 is not set and URG flag is not set - use the PDU Priority, Data priority and 
Data Importance from MEX_SNDATA_QOS_TBL. 

d) Protocol field is TCP, DSCP bit 5 is not set and URG flag is set - increase PDU Priority and Data priority by 1 
from MEX_SNDATA_QOS_TBL. Increase Data Importance by one point higher over the value stored in 
MEX_SNDATA_QOS_TBL. 

e) Protocol field is TCP, DSCP bit 5 is set and URG is not set - increase PDU and Data priority by 1 from 
MEX_SNDATA_QOS_TBL. Increase Data Importance by one point higher over the value stored in 
MEX_SNDATA_QOS_TBL. 

f) Protocol field is TCP, DSCP bit 5 is set and URG flag is set - increase PDU and Data priority by 2 from 
MEX_SNDATA_QOS_TBL. Increase Data Importance by one point higher over the value stored in 
MEX_SNDATA_QOS_TBL. 

Where it is not possible to increase PDU Priority, Data Priority or Data Importance, the highest value will be used. PDU 
Priority shall not exceed the returned PDU Priority max as specified by the SN-NSAPI Alloc Cnf when the PDP context 
was created. 

Whilst this escalation is only appropriate for the TETRA air interface, the MEX shall optionally reset bit 5 of the DCSP 
before forwarding the packet on to any further hops in the IP network. If this option is active, MEX should reset bit 5 of 
DCSP before transferring the packet to the SNDCP on the uplink and also before forwarding any downlink packets to 
the application. This option, by default, shall not reset bit 5 of DSCP. The option to enable the reset of bit 5 of DSCP is 
given during context creation and is provided to avoid any limitation in the wider usage of Diffserv in an end to end 
communication. 

By default the use of Bit 5 of DSCP for escalated priority shall be disabled. Usage can be enabled by the application 
during the MEX_CONNECT procedure. 

The SwMI may also provide escalated priority functionality in order to maintain escalated priority on both air interfaces 
of an MS to MS communication. 

30.2.4 Definition of MEX states and state transitions 
30.2.4.1 General 

At the highest level each transaction flow with the MEX layer has two major states as shown in figure 30.6. Each 
transaction flow is identified by "MEX Handle" which can represent the specific "MEX mode" by request. This allows 
multiple control and data streams to the MEX allowing the ability to transact across multiple logical PEI connections 
(PCONs) and to allow the instantiation and representation of multiple MS IP addresses in the TE2. 
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PEI Request 




On PEI Request 
Trigger SN-NSAPI Dealloc 

Figure 30.6: Activating, Bypassing IVIEX QoS features using IVIEX l-landle 

Individual states are described as follows: 

• Use MEX - All QoS functionality, including PDP service negotiation is managed by the MEX Layer; and 

• Bypass to SNDCP - All SNDCP services are directly accessible to the user application via the PEI. 

Within the Use MEX state, the following state machine given in figure 30.7 elaborates the use of the default 
background context for the support of legacy applications. 



MEX QoS Active 



PEI Requests 

Packet Mode 

(AT+WS46; ATD*99#) 



NSAPI Dealloc all 




Request for specific 
NSAPI with QoS 

Figure 30.7: Context creation state machine 

Individual states are described as follows: 

• IDLE - No NSAPIs are active, PEI only has one PCON in AT mode only; 

• NSAPIl Requesting - A Default, background class NSAPI is requested (MEX QoS Class = 0); 

• Default Context Active - Equivalent Legacy Context. All data is routed through this basic NSAPI; 
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• NSAPIN Requesting - The application has requested another context; and 

• Muhiple contexts active - Data is routed appropriately via the requested contexts. 

30.2.4.2 Secondary Contexts 

The concept of Secondary contexts is defined at the SNDCP to allow for different applications with different QoS 
requirements to operate over a PDP context with the same MS IP address. The MEX-CONNECT primitive has 
provision to request either a new MS IP address or attach a new application with differing QoS requirements to an 
existing IP address. It is the MEX responsibility to ensure that the appropriate SNDCP transactions occur to request 
either the primary or secondary NSAPI appropriately. 

30.2.4.3 MEX QoS Filter and Address/NSAPI mapping tables 

Four tables, internal to MEX, are defined in order to facilitate operation of the MEX QoS Filter, the use of NSAPI and 
IP addresses and parameters for compilation of the SN-DATA/SN-UNITDATA primitives. 

Table 30.4 illustrates MEX_CONTEXT_TBL table. MEX_CONTEXT_TBL is used to identify relationships between 
active PDP contexts. MEX_CONTEXT_TBL is used initially to store the unique MEX_Handle, when a particular 
MEX_Handle successfully initiates a PDP context, the MS IP address and associated NSAPI is stored. As the 
applications are only aware of IP Addresses and do not concern with NSAPI numbers, the MEX uses the mapping 
between MS IP Address and Primary NSAPI in order to facilitate the correct formulation of SN NSAPI Alloc requests 
for Secondary contexts. Successful creation of secondary contexts are entered into the MEX_CONTEXT_TBL 
table 30.4. 

Table 30.4: MEX CONTEXT TBL 



MEX Handle 


MS IP Address 


Primary NSAPI 


Secondary NSAPI 











.... 


.... 


.... 


.... 


.... 



Table 30.5 illustrates the MEX_QOS_FILTER_TBL table. Upon successful creation of a PDP context, 
MEX_QOS_FILTER_TBL is updated with the Uplink Destination Port Range and filter type (with optional Peer 
Destination IP Address), or DSCP, Filter Type as specified by MEX QoS Filter in MEX-CONNECT. The Upper and 
Lower MEX QoS Class for Uplink and Downlink are also stored to allow MEX to renegotiate QoS parameters upon a 
network initiated SN NSAPI Modify as described in clause 30.3.4. 

Table 30.5: MEX QOS FILTER TBL 



NSAPI 


Uplink 
Destination 
Port Range 


Peer 
Destination 
IP Address 


DSCP 


DSCP 

Priority 

Escalate 

Option 


Filter 
Type 


QoS 
Class 
Uplink 
Lower 


QoS 
Class 
Uplink 
Upper 


QoS 

Class 

Downlink 

Lower 


QoS 

Class 

Downlink 

Upper 
































.... 


.... 


.... 


.... 


.... 


.... 


.... 


.... 


.... 


.... 



Table 30.6 illustrates the MEX_QOS_AUTOFILTER_TBL table. When "MEX Transaction Type" is specified in MEX- 
CONNECT or MEX-MODIFY as "Uplink Automatic Filter", MEX_QOS_AUTOFILTER_TBL stores the details 
required to automatically generate entries into MEX_QOS_FILTER_TBL from downlink packets. For each NSAPI, a 
destination Port Range and filter type is specified (with optional downlink Source IP address). Entries in 
MEX_QOS_FILTER_TBL are updated based upon the following mappings: 

• Uplink packet Destination port - from the source port of the downlink packet; and 

• Uplink Peer Destination IP Address - from the source IP address of the downlink packet. 
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Table 30.6: MEX QOS AUTOFILTER TBL 



NSAPI 


Downlink Destination 
Port Range 


Downlink Source (Peer) 
IP address 


Filter Type 


.... 


.... 


.... 


.... 








.... 






Table 30.7 illustrates MEX_SNDATA_QOS_TBL table. During MEX-CONNECT and MEX-MODIFY, MEX PDU 
priority, MEX Data Priority and Data Importance are specified through entries of MEX QoS Class. These figures are 
stored in MEX_SNDATA_QOS_TBL to allow MEX to automatically fill the optional fields within the SN-DATA 
primitive for uplink packets. 

Table 30.7: MEX SNDATA QOS TBL 



NSAPI 


MEX PDU Priority 


MEX Data Priority 


MEX Data 
Importance 











.... 


.... 


.... 


.... 


.... 



30.3 MEX Procedures 



30.3.1 Services provided by tine protocol and QoS negotiations 

MEX performs the following functions: 

Processing PDP context activation, modification and PDP context deactivation requests; 

MEX precedence handling; 

Handling the QoS modification requests originating from the SNDCP layer and the MT and TE applications; 

Mapping of SN primitives received from the network layer into corresponding MEX messages to be passed to 
the MT and TE applications via the saps; and 

Routing TE2 and internal MT2 application data, to and from the SNDCP layer. 



30.3.2 MEX access procedure 

MEX-HANDLE is used to request and deallocate a handle from MEX and to also indicate whether any subsequent 
MEX communication should be dealt with by the MEX or routed direct to the SNDCP. 



TNMXxx SAP 



MEX 



1. MEX-HANDLE Req 



2. MEX-HANDLE Cnf 



Figure 30.8: Obtaining a handle for use with MEX procedures 

Each numbered step in figure 30.8 is explained in the following list: 

1) MEX-HANDLE Req is sent to the MEX requesting a "EX Mode". 
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2) MEX-HANDLE Cnf returns the "MEX Handle" which is to be used in subsequent MEX primitives. "MEX 
Handle" may also be returned as OxFF which is used to indicate a failure to supply a valid Handle. 

MEX primitives used without first using MEX-HANDLE can only originate from the default PCON and shall set a 
default handle of and shall be handled by the MEX layer for provisioning of the Legacy context (ATD*99# 
equivalent). 

MEX-HANDLE used where "MEX Mode" is "Deallocate Handle", shall tear down all associated PDP contexts. 

A MEX Handle is Deallocated only upon request or if the MS is powered off. 

30.3.3 MEX-CONNECT Procedure 

MEX-CONNECT is used to initiate a PDP context with a set of QoS parameters. 



TNMXxx SAP 



MEX 



SNDCP 



SwMI 



1. MEX-CONNECT 



6. MEX-CONNECT Cnf 



2. SN-NSAPI Alloc Req 



5. SN-NSAPI Alloc Cnf 



3. Act PDP Ctxt Demand 



4. Act PDP Ctxt Accept 



Figure 30.9: MEX-CONNECT procedure 

Each numbered step in figure 30.9 is explained in the following lists with respect to whether MEX is utilized or 
bypassed based upon the MEX Mode associated with the "MEX Handle" which is used. 

MEX Mode is "Use MEX": 

1 . MEX-CONNECT Req is sent to MEX with a MEX Handle, Port Range, transaction type and MEX QoS Class 
range and MEX PDP Type. 

2. MEX looks up the QoS parameters from the internal MEX QoS Class table using parameter MEX QoS Class 
Upper. Firstly, the QoS parameters of currently active contexts which have been intitated by MEX are 
investigated to assess the possibility to use a currently active context. Step 2. 1 Shall be followed if a currently 
active context is to be used. 

2.1. The procedures described in clause 30.3.4 are followed (without the originating MEX-MODIFY) taking into 
account the combined QoS of all applications currently using the context including the application which has 
made the MEX-CONNECT request. This shall ensure that all applications using the chosen context can remain 
within their requested MEX QoS Class range. Throughput parameters shall always be modified. 

2.2. If the current MEX-CONNECT cannot use an existing context the MEX sends a full SN-NSAPI Alloc Req to 
SNDCP. If the QoS Manager or application requires a new IP address (MEX PDP Type), parameter NS API is 
automatically chosen numerically from the unallocated pool of NSAPI 1 to 14. If PDP address is present, PDP 
Type is set to IPv4 (static address). If PDP Type is specified as Primary NSAPI (secondary PDP context 
requested), the MEX shall lookup the NSAPI from MEX_CONTEXT_TBL table and supply the primary 
NSAPI appropriately in SN-NSAPI Alloc. If MEX Handle is 0, the default MEX QoS Class shall be used. If 
MEX Data Priority Flag Reset is present then the QoS filter is enabled to reset bit 5 of DSCP upon data 
transfer. 

3. SNDCP demands the context from SwMI. 

4. The SwMI may set its Downlink QoS filter as requested. SwMI replies with a success or failure. 



£75/ 



1 1 04 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

5. SNDCP notifies MEX via SN-NSAPI Alloc Cnf. MEX inspects the returned QoS parameters and compares 
with the values of the MEX QoS Class table pointed to by "MEX QoS Class Lower". If one or more of the 
returned QoS parameters are returned specifying a lower QoS capability than those specified by "MEX QoS 
Class Lower" then the MEX-MODIFY procedure is subsequently used with parameters of "MEX QoS Class 
Lower". Step 6 is then returned accordingly. 

6. Upon successful creation or attachement to an exisiting PDP context, MEX returns MEX-CONNECT Cnf with 
details of the final QoS parameters in operation. If an existing context is modified as described in step 2.1 then 
all applications originally using the modified context shall receive a MEX-MODIFY Ind as for the Network 
initiated MEX-MODIFY described by step 8 of figure 30.13 (clause 30.3.4). MEX updates 
MEX_CONTEXT_TBL table. If MEX transaction type is "Uplink Filter" MEX updates 
MEX_QOS_FILTER_TBL table. If MEX transaction type is "Uplink Automatic Filter", MEX updates 
MEX_QOS_AUTOFILTER_TBL table. If a subsequent MEX-MODIFY is attempted in Step 5 and returns 
QoS parameters specifying a lower QoS capability than those specified by "MEX QoS Class Lower" MEX- 
CONNECT Cnf, MEX Connect Report shall equal Failure and MEX Connect reject Cause shall equal 
Requested QoS not available An additional SN-NSAPI Dealloc req shall be sent to the SNDCP to deactivate 
the corresponding PDP context. 

MEX mode is "Bypass to SNDCP": 

1 . MEX-CONNECT is sent to MEX with all PDP Context creation and QoS parameters except "MEX 
Precedence". MEX Transaction types "uplink filter" and "Automatic uplink filter" are not available. 

2. MEX directly forwards, or if necessary, reformats and forwards the request as SN NS API Alloc Req to 
SNDCP. 

3. SNDCP demands the context from SwMI. 

4. SwMI replies with a success or failure. 

5. SNDCP notifies MEX via SN-NSAPI Alloc Cnf. 

6. MEX directly forwards or, if necessary, reformats and forwards SN NSAPI Alloc Cnf as MEX-CONNECT 
Cnf. 

30.3.4 MEX-MODIFY Procedure 

MEX-MODIFY can be either MS or Network initiated. For an MS initiated MEX-MODIFY, depending upon which 
QoS parameters are required to change, there are three different procedures which may be followed as shown in 
figures 30.10, 30.11 and 30.12. Depending upon the combination of QoS parameters which are required to change the 
functionality of figures 30. 10, 30. 1 1 and 30. 12 will be combined. 

By default, the description below assumes that MEX -HANDLE represents MEX Mode as "Use MEX". Exceptions are 
described throughout. 

The following sequence charts illustrate all distinct combinations of transactions required to achieve MEX-MODIFY 
functionality. In many cases, combinations of these transactions are required. Where this is necessary, only one MEX- 
MODIFY Cnf should be returned for each MEX-MODIFY Req. 

Where a context is shared by several applications, a MEX-MODIFY Req from a single application must not infer a 
lower QoS on to the sharing applications. 

Figure 30.10 illustrates the transactions required with MEX where MEX Precedence, PDU Priority, Data Importance 
and/or MEX QoS Filter, has changed or MEX Filter Operation is present. 
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TNMXxx SAP 



MEX 



1. MEX-MODIFYReq 



2. MEX-MODIFYCnf 



Figure 30.10: MEX-MODIFY where MEX Precedence, PDU Priority, Data Importance 
and/or IVIEX QoS Filter, has changed or MEX Filter Operation is present 

Each numbered step in figure 30. 10 is explained in the following list: 

1 . MEX-MODIFY Req is sent to MEX where MEX Precedence, PDU Priority and/or Data Importance, uplink 
MEX QoS Filter has changed or MEX Filter Operation is present. MEX internally modifies its 
MEX_QOS_FlLTER_TBL, MEX_QOS_AUTOFlLTER_TBL and MEX_SNDATA_QOS_TBL and MEX 
Precedence buffers. 

2. MEX-MODIFY Cnf is returned. 

This transaction is not appropriate where MEX-HANDLE represents MEX Mode as "Bypass to SNDCP". 
Figure 30. 11 illustrates the transactions required with MEX when only "MEX Data Priority" has changed. 



TNMXxx SAP 



MEX 



SNDCP 



1. MEX-MODIFY Req 



4. MEX-MODIFY Cnf 



2. SN-NSAPI 
CONFIGURE Req 

3. SN-NSAPI 
CONFIGURE Cnf 



Figure 30.11 : MEX-MODIFY where Data Priority has changed 

Each numbered step in figure 30. 1 1 is explained in the following list: 

MEX-MODIFY Req is sent to MEX where Data Priority has changed. 

SN-NSAPI CONFIGURE Req is sent to SNDCP with the requested default Data Priority. 



SNDCP agrees a change in default Data Priority with the SwMI. SN-NSAPI CONFIGURE Cnf is then 
returned to MEX. Where "NSAPl Modify Report" is returned with Success, MEX updates 
MEX_SNDATA_QOS_TBL. 

4. MEX-MODIFY Cnf is returned. 

Where MEX-HANDLE represents MEX Mode as "Bypass to SNDCP", this transaction is only applicable where ONLY 
Data Priority has changed. 

Figure 30.12 illustrates the transactions required with MEX where other QoS parameters have changed or "MEX 
NSAPI Usage" is requested. 
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TNMXxx SAP 



MEX 



SNDCP 



SwMI 



1 . MEX-MODIFY Req 



6. MEX-MODIFY Cnf 



2. SN-NSAPI Modify Req 



5. SN-NSAPI Modify Cnf 



3. Modify PDP context 

Req 

4. Modify PDP context 

Cnf 



Figure 30.12: MS initiated IVIEX-IVIODIFY 

Each numbered step in figure 30.12 is explained in the following list: 

1 . MEX-MODIFY Req is sent to MEX. If "MEX Data Priority" has changed, the SN-NSAPI CONFIGURE 
procedure shall be carried out according to Figure 30. 1 1 above in advance of the following steps except for 
MEX MODIFY Cnf which shall be sent as a single instance in step 6 below. This extra step is not applicable 
where MEX-HANDLE represents MEX Mode as "Bypass to SNDCP2". 

2. SN-NSAPI MODIFY Req is sent to SNDCP with the requested modifications to NSAPI QoS Negotiation. 

3. SNDCP requests modifications from SwMI. 

4. SwMI may update its QoS Filter based upon any new downlink filter parameters. SwMI confirms 
modifications to SNDCP. 

5. SN-NSAPI MODIFY Cnf is returned to MEX. On success, MEX updates its internal tables and/or MEX 
precedence buffers appropriately. 

6. MEX-MODIFY Cnf is returned. 

Figure 30.13 illustrates a network initiated MEX-MODIFY. 



TNMXxx SAP 



MEX 



3. MEX-MODIFY Req 



4. MEX-MODIFY Cnf 



8. MEX-Modify Ind 



SNDCP 



SwMI 



1. Modify PDP context 
Req 



2. SN-NSAPI Modify Req 



5. SN-NSAPI Modify Cnf 6. Modify PDP context 
> Cnf 



7. SN-NSAPI Modify Ind 



Figure 30.13: Networit initiated lUIEX-IUIODIFY 
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Each numbered step in figure 30. 12 is explained in the following list: 

1 . SwMI Requests a modification to the context. 

2. SNDCP forwards appropriately to MEX using SN-NSAPI Modify Req. MEX may lookup the requested QoS 
modification to check if this specifies a higher QoS capability than the appropriate "MEX QoS Class Lower" 
entry for the NSAPl. Should this be true, steps 3 and 4 are bypassed. Where MEX-HANDLE represents MEX 
Mode as "Bypass to SNDCP", SN-NSAPI Modify Req is forwarded directly using MEX-MODIFY Req in 

step 3. 

3. The application is notified of the requested modification using MEX-MODIFY Req. 

4. The application replies using MEX-MODIFY Cnf. Where MEX-HANDLE represents MEX Mode as "Bypass 
to SNDCP", SN-NSAPI Modify Cnf is forwarded directly. 

5. MEX forwards the confirmation to SNDCP using SN Modify Cnf. 

6. SNDCP forward confirmation to SwMI. 

7. Upon a successful modification SN NSAPI Modify Ind is send to the MEX. MEX shall update its tables 
accordingly. Where MEX-HANDLE represents MEX Mode as "Bypass to SNDCP", SN-NSAPI Modify Ind is 
forwarded directly using MEX-MODIFY Ind in step 8. 

8. Application is notified of the new QoS modification using MEX-MODIFY Ind. Note that this may the first 
indication to the application of any QoS modification should the new QoS parameters exceed the originally 
requested "MEX QoS Class Lower" as described in step 2. 

Where a context modification is initiated by the network and the context is shared by multiple applications, each 
application shall receive a MEX-MODIFY Req with an appropriate proportion of the full context throughput to the 
originating request. Each application shall reply with a MEX-MODIFY Cnf before step 5 can continue. Each 
application using the shared context shall also receive the MEX-MODIFY Ind as described in step 8. 

MEX-MODIFY Ind is also sent, unsolicited, direct from the MEX upon a change of the overall MEX Precedence 
ranking as described in clause 30.2.3.3. 

30.3.5 MEX connection termination procedure 

The following describes the procedure for terminating a PDP context. Termination can be either MS or Network 
initiated, both of which are described below. 

Figure 30.14 illustrates an MS initiated Context Deactivation. 



TNMXxx SAP 



MEX 



1.MEX-ENDReq 



6. MEX-END Cnf 



SNDCP 



2. SN-NSAPI Dealloc Req 



5. SN-NSAPI Dealloc Cnf 



SwMI 



3. Deact PDP Ctxt 
Demand 

4. Deact PDP Ctxt Accept 



Figure 30.14: MS initiated PDP Context Deactivation 
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Each numbered step in figure 30. 14 is explained in the following list: 

1 . The application on the MS initiates a MEX-END Request. If Deactivation type is "Deactivate all MEX 
Contexts" then steps 2-5 shall be carried out for each active PDP context which has been created by the MEX 
layer. 

2. SN_NSAPI Dealloc Req is sent to SNDCP. 

3. Deactivate PDP Context Demand is sent to SwMl. 

4. SwMl replies with acceptance. 

5. SN-NSAPI Dealloc Cnf Confirms to MEX. MEX removes all appropriate entries from internal tables. 

6. MEX informs the application of successful deactivation. 
Figure 30. 15 illustrates a Network initiated Context Deactivation. 



TNMXxxSAP 



MEX 



SNDCP 



SwMl 



4. MEX-END Ind 



2. SN-NSAPI Dealloc Ind 



1 . Dead PDP Ctxt 
Demand 



3. Deact PDP Ctxt Accept 



Figure 30.15: Network initiated PDP Context Deactivation 

Each numbered step in figure 30.15 is explained in the following list: 
SwMI Demands PDP Context Deactivation. 
SNDCP forwards the Deactivation using SN-NSAPI Dealloc Ind. 



MEX determines all active MEX Contexts for the Deactivation of the requested NSAPI and removes all 
appropriate entries from internal tables. 

MEX-END Ind notifies the application of the deactivation of either a single or all PDP contexts. Where a 
single NSAPI deactivation is given by SN-NSAPI Dealloc and multiple MEX Contexts are active on the single 
NSAPI, a MEX-END Ind shall be sent for each appropriate MEX Context. 



30.3.6 MEX QoS Abstract Class Table Management 

The following describes the procedure for accessing the MEX QoS Class table. 



TNMXxx SAP 



MEX 



1 . MEX-QOSCLASS Req 



2. MEX-QOSCLASS Cnf 



Figure 30.16: IVIanaging the IVIEX QoS Abstract Class table 
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Each numbered step in figure 30. 16 is explained in the following list: 

1. The application requests indication, update and or locking of a MEX QoS Class entry. MEX QoS Class Access 
is used to request the read, write and lock functionality. If MEX QoS Class Access is "Write and Lock" the 
specified MEX QoS class entry shall only be writeable when the specified MEX Handle is stated. MEX QoS 
Class Access "Unlock" shall be used to release the entry for subsequent access using any MEX Handle. 

2. MEX returns confirmation that the entry has been updated (if applicable) together with the full list of QoS 
parameters in the requested class. 

A lock on a MEX QoS Class entry shall be automatically released upon the termination of all contexts which use the 
MEX QoS Class entry. All locks shall be released upon power off of the MS. 

30.3.7 MEX data routing procedure 
30.3.7.1 Uplink Data Service 

The following describes the procedure for data routing in the uplink service. 

When using MEX services and an acknowledged service is utilized, the MEX shall allocate and keep track of SN- 
DATA handles paired with SN-DELIVERY returns. Where SN-DELIVERY returns with either Failure or Deletion by 
SNDCP report, or no SN-DELIVERY is received then the MEX shall return the full IP header together with the first 
64 bytes of data back to the application through the PEI to allow for implementation of ICMP signalling support in the 
TE2 or MT2 IP stack. 

Note that in the following description, the SNDCP primitive SN-DATA is described. Where an unacknowledged 
service is used, the treatment of SN-DATA should be replaced by SN-UNITDATA. 



TNMXxx SAP 



MEX 



SNDCP 



1 . MEX-DATA Req 



-^ 2. SN-DATA Req 



5. SN-DELIVERY Ind 



6. MEX-DELIVERY Ind 



SwMI 



3. SN-DATA Req 



4. SN-DATA Ind 



Figure 30.17 MS initiated Data Routing 

Each numbered step in figure 30.17 is explained in the following list: 

1 . MEX-DATA Req is either an IP packet to be transferred to the network or a MEX-B YPASS DATA Req 
encapsulating a full SNDCP SN-DATA Req primitive. 

2. MEX prepares and sends an SN-DATA Req to SNDCP. The MEX inspects the Destination port. Destination 
Address and DSCP of the IP packet and decides which NSAPI should be used, by using 
MEX_QOS_FlLTER_TBL. SN-DATA Handle is assigned and recorded ready for checking of a receipt of 
SN-DELIVERY. PDU Priority, Data Priority, Data Importance of SN-DATA are set according the appropriate 
entry in MEX_SNDATA_QOS_TBL. The IP packet is inspected and priority escalated appropriately 
according to clause 30.2.3.9.. The Schedule Surplus flag is set should the MEX recognize an excess of data 
over and above any accepted schedule. Where MEX-HANDLE represents MEX Mode as "Bypass to 
SNDCP2, MEX-DATA Req is forwarded, with any necessary reformatting, directly to SNDCP. 

3. SN-DATA Req is sent across the air interface to the SwMl. 

4. SwMl forwards SN-DATA Ind to the IP network. 
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5. If an acknowledged service is utilized, SN-DELIVERY is sent to MEX. MEX checks the SN-DELIVERY 
Handle against those recorded at step 2. 

6. If SN-DELIVERY Delivery Report is "Failure" or "Deleted or Cancelled by SNDCP" then MEX DELIVERY 
is sent to the application. 

30.3.7.2 Downlink Data Service 

The following describes the procedure for data routing in the downlink service. 

Note that in the following description, the SNDCP primitive SN-DATA is described. Where an unacknowledged 
service is used, the treatment of SN-DATA should be replaced by SN-UNITDATA. 



TNMXxx SAP 



MEX 



SNDCP 



SwMI 



4. MEX-DATA Ind 



2. SN-DATA Ind ^ 



1 . SN-DATA Req 



3. SN-DATA Ind ^ 



Figure 30.18: SwMI initiated Data Routing 

Each numbered step in figure 30.18 is explained in the following list: 

1 . SwMI receives SN-DATA Req from the network. 

2. SN-DATA Ind is received over the air interface by SNDCP. 

3. SN-DATA Ind is sent to MEX. The IP packet is inspected for Destination port and source IP address. 
MEX_QOS_AUTOFILTER_TBL is compared and MEX_QOS_FILTER_TBL is updated accordingly as 
described in clause 30.2.4.3. If the option MEX Escalate Flag Reset was present at MEX-CONNECT for the 
NSAPI, the MEX shall reset bit 5 of DSCP prior to forwarding the packet (clause 30.2.3.9). 

4. MEX forwards the data to the appropriate SAP using MEX-DATA Ind containing either an IP packet or 
MEX-BYPASS DATA Ind primitive. 



30.3.7.3 



Maximum Transmission Unit 



Where MEX-DATA on the uplink represents an IP packet which exceeds the state Maximum Transmission Unit, a 
MEX-DELIVERY Ind shall be returned to the application to allow the possibility to utilize the ICMP Destination 
unreachable Message (RFC 792 [i.l4]) to indicate through the MT2 or TE2 IP stack. Path MTU discovery (PMTUD) 
(RFC 1191 [i. 15]) can therefore be utilized by the TE2 IP stack to determine the appropriate MTU to use. 



30.3.7.4 



Scheduled access 



The MEX shall remain aware of any uplink MEX-DATA request primitives which are intended to make use of the 
scheduled access service. The MEX shall keep a count and detect any increase in the quantity of data exceeding the 
requested schedule. In such case where the schedule is exceeded, the MEX shall send extra SN-DATA with the 
Schedule Surplus Flag set, as appropriate, so as not to loose any data. 
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30.3.7.5 MEX-QOS 



The MEX-QOS request primitive is a direct mapping to SN-QoS in the SNDCP and is retained for backward 
compatibihty with previous versions of SNDCP, and is appHcable only to 7t/4-DQPSK modulation. The optional MEX 
NSAPI QoS negotiation parameter included in the MEX-CONNECT and MEX-MODIFY primitives has more general 
applicability, and should be used instead of the MEX-QOS request primitive. 

MEX-QOS is only available at TNMXIT_SAP and not available through the PEI via TNMXPI SAP. 

30.3.7.6 Packet mode Paging 

The MEX-PAGE primitive is a direct mapping to SN-PAGE in the SNDCP. 

MEX-PAGE is only available at TNMXIT_SAP and not available through the PEI via TNMXPI SAP. 

30.4 MEX service description 

30.4.1 Introduction 

Clause 30.4 describes the services offered by the Multimedia Exchange (MEX) entity for the voice plus data TETRA 
layer 3 air interface. 

30.4.2 Services offered 

MEX shall be a service provider for packet data users. 

The services offered shall be: 

Receiving MEX access requests from the MT and TE applications; 

Filtering TE and MT application data to the appropriate PDP context and QoS by monitoring the port numbers, 
IP addresses and DSCP encapsulated within IP datagrams; 

Receiving the QoS requirements from the MT and TE applications; 

Negotiating application QoS requirements with the SNDCP layer; 

Management of MEX precedence specified by the MT and TE applications using internal buffering and a 
switching function; and 

Providing feedback on the changing QoS values to the MT and TE applications. 

30.4.3 Service Primitives 
30.4.3.1 General on service primitives 

The services shall be provided using MEX messages to the PEI via TNMXPI SAP and MT2 internal applications via 
TNMXIT SAP. Access to the SNDCP primitives is via the SN-SAP. This clause describes the primitives and their 
parameters. 

The MEX services consist of the following messages: 

MEX-CAP ABILITY 

MEX-CONNECT; 

MEX-DATA 

MEX-DELIVERY 

MEX-END; 



£75/ 



1112 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



MEX-HANDLE; 
MEX-MODIFY; and 
MEX-QOSCLASS 
In parameter descriptions: 
C = Conditional; 
M = Mandatory; and 
O = Optional. 

30.4.3.2 M EX-CAPABILITY 

The parameters for the primitive MEX-CAP ABILITY shall be as defined in table 30.8. 

Table 30.8: Parameters for the primitive IVIEX-CAP ABILITY 



Parameter 


Req 


Ind 


MEX Handle 


M 


M 


MEX Capability 


M 


M 
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30.4.3.3 MEX-CONNECT 

The parameters for the primitive MEX-CONNECT shall be as defined in table 30.9. 

Table 30.9: Parameters for the primitive IVIEX-CONNECT 
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Parameter 


Req 


Cnf 


MEX Handle 


M 


M 


MEX QoS Filter 





- 


MEX QoS Class Uplink Upper 


C (see note 2) 


- 


MEX QoS Class Uplink Lower 


C (see note 2) 


- 


MEX QoS Class Downlink Upper 





- 


MEX QoS Class Downlink Lower 





- 


MEX Escalate DSCP5 Flag Enable 





- 


MEX Escalate DSCP5 Flag Reset 





- 


MEX Connect Report 


- 


M 


MEX Connect Reject Cause 


- 


C (see note 6) 


Maximum Transmission Unit 


- 


M 


MEX PDP Type 


M 


C (see note 5) 


MEX PDP Address 


C (see note 5) 


C (see note 5) 


NSAPI 


C (see note 3) 


- 


DCOMP 


(see notes 3 and 4) 


(see note 3) 


PCOMP 


(see notes 3 and 4) 


(see note 3) 


NSAPI QoS Negotiation 


(see notes 3 and 4) 


(see note 3) 


NSAPI Data Priority 


(see notes 3 and 4) 


- 


PDU Priority Max 


- 


C (see note 5) 


Mobile IPv4 Information 


- 


C (see note 5) 


MEX Precedence 


- 


C (see notes 2 and 8) 


NOTE 1 : Provided if mapping of data is filtered by both IP address and Port 

NOTE 2: Only used if the "MEX Handle" was returned with MEX mode as "Use MEX" 

NOTE 3: Only used if the "MEX Handle" was returned with MEX mode as "Bypass to SNDCP" and 

the values has changed. Refer to SN-NSAPI Alloc, refer to clause 28.2.3.1 . 
NOTE 4: Optional, refer toSN-NSAPI Alloc, refer to clause 28.2.3.1 . 
NOTE 5: Shall be present, if MEX connect report is "Success (OoS parameter changed)". Refer to 

SN-NSAPI Alloc, refer to clause 28.2.3.1. 
NOTE 6: Present if MEX Report is "Failure" 
NOTE 7: Not present if MEX Report is "Failure" 
NOTE 8: MEX Precedence for Cnf will return the overall ranking of MEX precedence rather than 

the requested MEX Precedence as described in clause 30.2.3.3. 



30.4.3.4 MEX-BYPASS DATA 

The parameters for the primitive MEX-BYPASS DATA shall be as defined in table 30.10. 

Table 30.10: Parameters for the primitive MEX-BYPASS DATA 



Parameter 


Req 


Ind 


MEX Handle 


M (see note 1 ) 


M (see note 1) 


NSAPI 


C (see note 2) 


C (see note 2) 


Data Handle 


C (see note 2) 


- 


PDU Priority 


C (see note 2) 


- 


Data Priority 


C (see note 2) 


- 


Data Importance 


C (see note 2) 


- 


Schedule Surplus Flag 


C (see note 2) 


- 


MEXN-PDU 


M 


M 


NOTE 1 : The MEX Handle shall be set to "Bypass to SNDCP" 

NOTE 2: The parameter shall be present if MEX Handle represents "Bypass to SNDCP" 
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30.4.3.5 MEX-DELIVERY 

The parameters for the primitive MEX-DELIVERY shall be as defined in table 30. 11. 

Table 30.11 : Parameters for the primitive lUIEX-DELIVERY 



Parameter 


Ind 


MEX Handle 


M 


Data Handle 


C (see note 1) 


MEX Delivery Report 


M 


MEX Delivery Header 


C (see note 2) 


NOTE 1 : Only present if MEX Handle represents "Bypass to SNDCP" 
NOTE 2 : Only present if MEX Handle represents "Use MEX" 



30.4.3.6 MEX-END 

The parameters for the primitive MEX-END shall be as defined in table 30.12. 

Table 30.12: Parameters for the primitive MEX-END 



Parameter 


Req 


Ind 


Cnf 


MEX Handle 


M 


M 


M 


NSAPI 


C (see note) 


C (see note) 


C (see note) 


MEX Deactivation Type 


M 


M 


M 


NOTE: Only present if MEX Handle represents "Bypass to SNDCP". 



30.4.3.7 MEX-HANDLE 

The parameters for the primitive MEX-HANDLE shall be as defined in table 30. 13. 

Table 30.13: Parameters for the primitive MEX-HANDLE 



Parameter 


Req 


Ind 


MEX Handle 


M 


M 


MEX Mode 


M 


M 
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30.4.3.8 MEX-MODIFY 

The parameters for the primitive MEX-MODIFY shall be as defined in table 30. 14. 

Table 30.14: Parameters for the primitive lUIEX-IUIODIFY 
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Parameter 


Req 


Ind 


Cnf 


MEX Handle 


M 


M 


M 


MEX QoS Filter 





- 


- 


MEX Filter Operation 





- 


- 


IVIEX QoS Class Uplink Upper 


C (see note 1 ) 


- 


- 


MEX QoS Class Uplink Lower 


C (see note 1 ) 


- 


- 


MEX QoS Class Downlink Upper 


C (see notes 1 and 7) 


- 


- 


MEX QoS Class Downlink Lower 


C (see notes 1 and 7) 


- 


- 


MEX Modify Report 


- 


- 


M 


MEX Modify Reject Cause 


- 


- 


C (see note 4) 


MEX NSAPI Usage 





- 


- 


NSAPI QoS Negotiation 


C (see notes 2 and 3) 


C (see notes 2 and S) 


C (see notes 1 and 2) 


Schedule Availability 


- 





- 


MEX Precedence 


- 


C (see notes 1 and 6) 


C (see notes 1 and 6) 


NOTE 1 
NOTE 2 
NOTES 
NOTE 4 
NOTES 
NOTE 6 

NOTE 7 


Only used if the "MEX Handle" was returned with MEX mode as "Use MEX". 

Only used if the "MEX Handle" was returned with MEX mode as "Bypass to SNDCP". 

Optional as for SN-NSAPI Modify. 

Present if MEX Report is "Failure". 

Not present if MEX Report is "Failure". 

MEX Precedence for Ind and Cnf will return the overall ranking of MEX precedence rather than the 

requested MEX Precedence as described in clause 30.2.S.S. 

Only if SNDCP supports Asymmetric QoS. 



30.4.3.9 MEX-PAGE 

The parameters for the primitive MEX-PAGE shall be as defined in table 30.15. 

Table 30.15: Parameters for the primitive MEX-PAGE 



Parameter 


Indication 


Response 


NSAPI 


M 


M 


Reply requested 


M 


- 


PD service status 


- 


M 



30.4.3.10 MEX-QOS 

The parameters for the primitive MEX-QOS shall be as defined in table 30.16. 

Table 30.16: Parameters for the primitive MEX-QOS 



Parameter 


Request 


Indication 


OoS requested 


M 


M 


OoS minimum 


M 


- 


OoS negotiated 


- 


M 


OoS negotiation result 


- 


M 


NOTE: It is recommended that this primitive is used only to set parameters 
within the MS SNDCP entity, to be used at a later stage during 
advanced link setup negotiation. This primitive should not in itself 
trigger the establishment or resetting of the advanced link. 
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30.4.3.1 1 MEX-QOSCLASS 

The parameters for the primitive MEX-QOSCLASS shall be as defined in table 30.17. 

Table 30.17: Parameters for the primitive IVIEX-QOSCLASS 



Parameter 


Req 


Cnf 


MEX Handle 


M 


M 


MEX QoS Class 


M 


M 


MEX QoS Class Access 


M 


M (see note 2) 


MEX QoS 


C (see note 1) 


M 


MEX Precedence 


C (see note 1) 


M 


MEX Data Priority 


C (see note 1) 


M 


MEX PDU Priority Max 


C (see note 1 ) 


M 


MEX Data Importance 


C (see note 1) 


M 


NOTE 1 : Not present is MEX QoS Class Access is "Read". 

NOTE 2: "Read" is indicated if the MEX QoS Class is Read Only. "Write" is indicated if the "MEX 
QoS Class" entry has been updated. 



30.4.4 MEX Parameters 

MEX Parameters are described in detail in the following list. Note that many parameters are derived directly from their 
original definition within clause 28. Some of these parameters have been modified for appropriate operation with the 
MEX layer primitives described above. Those which have modifications with respect to those defined in clause 28 are 
prefixed with "MEX". Those which are identical to the SNDCP parameters do not have this prefix. 

30.4.4.1 Data Handle 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP Data Handle parameter. See 
clause 28.1 for a full definition as apphed to SN-DATA and SN-UNITDATA. 

30.4.4.2 Data Importance 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP Data Importance parameter. See 
clause 28.1 for a full definition as appHed to SN-DATA and SN-UNITDATA. 

30.4.4.3 Data Priority 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP Data Priority parameter. See 
clause 28.1 for a full definition as appHed to SN-DATA and SN-UNITDATA. 

30.4.4.4 DCOMP 

This parameter may contain several different data compression methods, such as ITU T Recommendation V.42bis [27], 
and their parameters negotiated with the peer entity. 

30.4.4.5 Maximum Transmission Unit 

This is the maximum size of N PDU which may be presented by the MS service user to SNDCP for transport over the 
air interface. This typically represents the maximum size of IP packet (prior to adding SNDCP header and performing 
compression) which may be carried over the air interface. 

30.4.4.6 MEX Capability 

• MEX Precedence is supported; or 

• MEX Precedence is not supported. 
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30.4.4.7 MEX Connect Reject Cause 

Undefined; 

MS not provisioned for Packet Data; 

IPv4 not supported; 

IPv6 not supported; 

IPv4 dynamic address negotiation not supported; 

IPv6 stateful address autoconfiguration not supported; 

IPv6 stateless address autoconfiguration not supported; 

Dynamic address pool empty; 

Static address not correct; 

Static address in use; 

Static address not allowed; 

Static IP address congestion; 

TETRA Packet Data not supported on this location area; 

TETRA Packet Data not supported on this network; 

Temporary rejection; 

Packet Data MS Type not supported; 

SNDCP version not supported; 

Mobile IPv4 not supported; 

Mobile IPv4 Co-located Care of Addresses not supported; 

Maximum allowed PDP contexts per ITSI exceeded; 

User authentication failed; 

Activation rejected by external PDN; 

Access point name index not correct; 

No response from network; 

Bad response from network; 

NSAPI not available; 

NSAPI already allocated; 

Requested minimum peak throughput not available; 

Scheduled access not supported; 

Requested schedule not available; 

Requested QoS not available; 

Secondary PDP contexts not supported; 

Primary PDP context does not exist; 
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Asymmetric QoS not supported; 

Automatic QoS filter not supported; 

Specified QoS filter not supported; or 

QoS filter type not supported; or 

QoS filter not available for primary PDP context. 

30.4.4.8 MEX Connect Report 

• Failure; 

• Success (not used in "Bypass to SNDCP" mode); or 

• Success QoS Parameters changed. 

30.4.4.9 MEX Deactivation Type 

• Deactivate all NSAPIs; 

• Deactivate all MEX Contexts (NOTE: only in Use MEX mode); or 

• Deactivate all contexts associated with the MEX Handle given in the primitive. 

30.4.4.10 MEX Delay Class 

• Low; 

• Moderate; 

• High; or 

• Unpredictable. 

30.4.4.1 1 MEX Delivery Header 

This parameter consists of the full IP header plus the first 64 bytes of data of the IP packet for delivery failed. The 
intended provision of this data is to allow the possibility to utilize the ICMP Destination Unreachable Message 
(RFC792) to indicate through the TE2 or MT2 IP stack. 

30.4.4.12 MEX Delivery Report 

Success; 

Failure; 

Deleted or cancelled by SNDCP; 

Packet exceeds MTU (Only used if MEX Handle represents "Use MEX"); or 

Packet was Surplus to Schedule (Only used if MEX Handle represents "Use MEX"). 

30.4.4.13 MEX Escalate DSCP5 Flag Enable 

Parameter is present in MEX-CONNECT to specify that the Diffserv bit 5 shall be used for pritotiy escalation as 
described in clause 30.2.3.9. 
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30.4.4.14 MEX Escalate DSCP5 Flag Reset 

Parameter is present in MEX-CONNECT to specify that the Diffserv bit 5 shall be reset before an IP packet is 
forwarded from the MEX. 

30.4.4.15 MEX Filter 

• A range of IP Ports; or 

• a DSCP. 

30.4.4.16 MEX Filter Operation 

• Add this QoS filter to any existing QoS filter for this PDP context; 

• Replace any existing QoS filter for this PDP context by this QoS filter; or 

• Remove this QoS filter from the existing QoS filter for this PDP context. 

30.4.4.17 MEX Filter Type 

Automatic; 

All types of ports; 

UDP Only; 

TCP Only; or 

Diffserv. 

NOTE: Diffserv is not applicable to either the "Automatic Uplink Filter" or "Automatic Downlink Filter" MEX 
Transaction types. 

30.4.4.18 MEX Handle 

Use to indicate no Handle. Used to support legacy applications requiring a simply defined PDP context. 

1 to 254 Valid Handle identifiers. 

255 Used to indicate failure to generate a valid handle. Only used in confirmation or indication primitives. 

30.4.4.19 MEX IP Request 

Used only in "Bypass to SNDCP mode". 

30.4.4.20 MEX Mode 

• Use MEX; 

• Bypass to SNDCP; or 

• Deallocate Handle. 

30.4.4.21 MEX Modify Report 

Where an application is working with "Bypass to SNDCP" MEX handle, MEX Modify Report shall mimic SNDCP 
NSAPI Modify Report (see clause 28.2.3.2). 

• Failure (No parameters are change from their previous value). 
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Success Local (One or more of MEX Precedence, PDU Priority, Data Importance, Data Priority have changed 
from their previous value). 

Success (One or more of the MEX NS API QoS parameters were changed from their previous value). 

Full Success (All requested parameter changes have been made). 



30.4.4.22 MEX Modify Reject Cause 

Undefined; 

Temporary rejection; 

No response from network; 

Bad response from network; 

NSAPI not activated; 

Requested minimum peak throughput not available; 

Scheduled access not supported; 

Requested schedule not supported; 

Requested QoS not available; 

Secondary PDP contexts not supported; 

Primary PDP context does not exist; 

Asymmetric QoS not supported; 

Automatic QoS filter not supported; 

Specified QoS filter not supported; or 

QoS filter type not supported; or 

QoS filter not available for primary PDP context. 

30.4.4.23 MEXN-PDU 

Any number of bits needed to carry a Network layer protocol PDU. This is typically the full IP packet. 

30.4.4.24 MEX NSAPI Usage 

• Schedule paused; or 

• PDP context paused. 

30.4.4.25 MEX PDP Address 

• IPv4 address (only when a primary PDP context is being requested); or 

• NSAPI (only when a secondary PDP context is being requested). 

30.4.4.26 MEX PDP Type 

• IPv4 (static address); 

• IPv4 (dynamic address negotiation); 
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• IPv6; 

• Mobile IPv4 - Foreign Agent care of address requested; 

• Mobile IPv4 - Co-located care of address requested; or 

• Primary NSAPI (secondary PDP context requested). 

30.4.4.27 MEX Peer IP Filter 

An IP address of a network node for which the MS is intended to communicate with. 

30.4.4.28 MEX Precedence 

See clause 30.2.3.3 for full description of the MEX Precedence. 

30.4.4.29 MEXQoS 

• A set of: 

Data Class (see clause 30.2.2.1); 

Delay Class (see clause 30.2.2.2); 

Reliability Class (see clause 30.2.2.3); 

Minimum Peak Throughput (see clause 30.2.3.2); 

Mean Throughput (see clause 30.2.3.2); 

Mean Active Throughput (see clause 30.2.3.2); 

MEX Precedence (see clause 30.2.3.3); 

Data Priority (see clause 30.2.3.4); 

PDU Priority (see clause 30.2.3.5); 

Data Importance (see clause 30.2.3.6); 

Schedule Repetition Period (see clause 30.2.3.7); 

Scheduled Number of IP Packets (N-PDUs) per grant (see clause 30.2.3.7); 

Scheduled IP Packet (N-PDU) size (see clause 30.2.3.7); 

Schedule Timing Error (see clause 30.2.3.7); and 

CONTEXT Ready Timer (see clause 30.2.3.8). 

30.4.4.30 MEXQoS Class 

Identifier of the default QoS settings for a legacy PDP context creation; 

1 to 8 Identifiers of Specified QoS Class parameters; 

9 to 32 Identifiers of Manufacturer set Read Only QoS Class parameters; or 
33 to 255 Identifiers of User writable QoS Class parameters. 

30.4.4.31 MEX QoS Class Uplink/Downlink Upper/Lower 

Values as for MEX QoS Class. 
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30.4.4.32 MEX QoS Class Access 

Read; 

Write; 

Write and Lock; 

Unlock; or 

Locked (Used only in MEX-QOSCLASS Cnf where a MEX QoS Class is locked). 

30.4.4.33 MEX QoS Filter 

• A set of: 

MEX Filter; 

MEX Peer IP Filter (optional) ; 
MEX Transaction Type; and 
MEX Filter Type. 

30.4.4.34 MEX Scheduled Access 

• A set of: 

schedule repetition period; 

schedule timing error; 

scheduled number of N-PDUs per grant; and 

scheduled N-PDU size. 

NOTE: The scheduled N PDU size parameter should be repeated as many times as necessary to indicate a size for 
each scheduled N PDU per grant. 

30.4.4.35 MEX Transaction Type 

• Uplink Filter (Not available when using "Bypass to SNDCP mode"); 

• Downlink Filter; 

• Uplink Automatic Filter (Not available when using "Bypass to SNDCP mode"); or 

• Downlink Automatic Filter. 

NOTE 1: Uplink Filter and Uplink Automatic Filter are not available when using "Bypass to SNDCP mode". 

NOTE 2: Uplink Automatic Filter and Downlink Automatic filter are not applicable when MEX Filter Type is 
"Diffserv". 

30.4.4.36 Mobile IPv4 Information 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP Mobile IPv4 Information parameter. 
See clause 28.1 for a full definition as applied to SN-NSAPI Alloc. 
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30.4.4.37 NSAPI 



This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP NSAPI parameter. See clause 28.1 
for a full definition as applied to SN-DATA, SN-NSAPI Alloc, SN-NSAPI Configure, SN-NSAPI Dealloc, SN-NSAPI 
Modify. 

30.4.4.38 NSAPI Data Priority 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP NSAPI Data Priority parameter. See 
clause 28.1 for a full definition as applied to SN-NSAPI Alloc and SN-NSAPI CONFIGURE. 

30.4.4.39 NSAPI QoS Negotiation 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP NSAPI QoS Negotiation parameter. 
See clause 28.1 for a full definition as applied to SN-NSAPI Alloc and SN-NSAPI Modify. 

30.4.4.40 PCOIVIP 

This parameter may contain several different protocol compression methods. They may be one or more of: TCP/IP 
header compression (not available for unacknowledged layer 2 service or real time class data) and IP header 
compression. 

30.4.4.41 PDU Priority 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP PDU Priority parameter. See 
clause 28.1 for a full definition as appHed to SN-DATA and SN-UNITDATA. 

30.4.4.42 PDU Priority Max 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP PDU Priority Max parameter. See 
clause 28.1 for a full definition as appHed to SN-NSAPI Alloc. 

30.4.4.43 Schelude availabilitity 

This parameter indicates availability of scheduled access, see clause 28.3.5.6. 

30.4.4.44 Schedule Surplus Flag 

This parameter is only used in "Bypass to SNDCP" mode and mimics the SNDCP Schedule Surplus Flag parameter. 
See clause 28.1 for a full definition as applied to SN-DATA and SN-UNITDATA. 
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Annex A (normative): 
LLC timers and constants 

This annex lists the LLC timers and constants in the MS. 

Where indicated, a value should be chosen by the MS designer from within a given range. For other timers and 
constants, a default value is given. The default value shall be used by the MS unless it received a different value when it 
subscribed to that network. 



A.1 LLC timers 



Timers T.251, T.252, T.261, T.263 and T.265 are defined in terms of downlink signalling frames for the control channel 
on which the downlink message is expected. When counting downlink signalling frames, the MS should normally count 
all frames, except that: 

• on an assigned channel, the MS shall count only those downlink frames that are available for control signalling 
on that channel; note, however, that the BS may choose to send a PDU to the MS by stealing from the 
downlink TCH; 

• when the MS transmits using reserved access on a multi-slot channel, if the MS is not frequency full duplex, 
then, when counting downlink frames, the MS shall count only those frames containing at least one slot that it 
is able to attempt to receive and decode and that is available for control signalling; 

• if the MS is transmitting traffic then: 

for timer T.251, and if the stealing repeats flag is set for the PDU being sent, the MS shall count all 
downlink frames (irrespective of whether they are available for control signalling); 

otherwise, the MS shall count only those downlink frames that it is required to monitor (according to the 
assigned monitoring pattern(s)) and that are available for control signalling; note, however, that the BS 
may choose to send a PDU to the MS by stealing from the downlink TCH in one of the monitored slots; 

NOTE 1: For a multi-slot channel, if the MS is not frequency full duplex, and if the BS assigns monitoring 

pattern(s) that the MS is not capable of following, then, when counting downlink frames, the MS counts 
only those frames containing at least one slot that it is able to monitor and that is available for control 
signalling. 

• if the MS is in minimum mode, the MS shall count only frame 18; note, however, that the BS may choose to 
send a PDU to the MS in slot 1 during frames 2 to 17; 

• on a time-shared MCCH, the MS shall count only frames reserved for this BS; note, however, that the BS may 
choose to send a PDU to the MS in one of the common frames. 

T.25 1 Sender re-try timer: 

• Default value = 4 signalling frames. 
T.252 Acknowledgement waiting timer: 

• Default value = 9 signalling frames. 
T.261 Set-up waiting timer: 

• Default value = 4 signalling frames. 
T.263 Disconnection waiting timer: 

• Default value = 4 signalling frames. 
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T.265 Reconnection waiting timer: 

• Default value = 4 signalling frames. 

T.271 Receiver not ready validity timer for the data sending entity: 

• Default value = 36 TDMA frames. 

NOTE 2: The value of this timer should exceed the value for the data receiving entity T.272. 
T.272 Receiver not ready validity timer for the data receiving entity: 

• Defauh value = 18 TDMA frames. 



A.2 LLC constants 



Constants N.252, N.253, N.262, N.263, N.265, N.273, N.274, N.282 and N.293 define the maximum number of 
retransmissions or repetitions. The maximum number of transmissions (including the first transmission) is therefore the 
specified value + 1 . 

N.251 Maximum length of TL-SDU (basic link): 

• This is the maximum length of one TL-SDU if the optional Frame Check Sequence (FCS) is used. 

• Default value = 2 595 bits (i.e. approximately 324 octets). 

• The FCS is optional. If the FCS is not used, the TL-SDU part may be larger by four octets. 
N.252 Maximum number of TL-SDU retransmissions for acknowledged basic link service: 

• MS designer choice from range 3 to 5 if the stealing repeats flag is set; 

• MS designer choice from range 1 to 5 if the stealing repeats flag is not set. 
N.253 Number of TL-SDU repetitions in unacknowledged basic link service: 

• MS designer choice from range to 5. 

NOTE 1 : The service user may indicate the required number of TL-SDU repetitions for a particular TL-SDU in the 
unacknowledged basic link service. The value of N.253 chosen by the MS designer applies when the 
service user does not indicate the required number of repetitions. 

N.261 Advanced link number: 

• This value is defined during the set-up of the advanced link (see AL-SETUP PDU definition). Range: (1; 4). 
N.262 Maximum number of connection set-up retries: 

• MS designer choice from range 1 to 5. 
N.263 Maximum number of disconnection retries: 

• MS designer choice from range 3 to 5. 

N.264 Number of 3i/4-DQPSK timeslots used per TDMA frame: 

• This value may be defined during the set-up of the advanced link (see AL-SETUP definition). Range: 1 to 4. 
N.265 Reconnection retries: 

• MS designer choice from range to 5. 
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N.271 Maximum length of TL-SDU (advanced link): 



• This is the maximum length of one TL-SDU including the FCS, it is defined during the set-up of the advanced 
hnk (see AL-SETUP PDU definition), Range: (32, 4 096) octets. 

N.272 Window size for TL-SDU in acknowledged service: 

• This value is defined during the set-up of the advanced link, (see AL-SETUP definition). 

Range: (1;3) for the original advanced link. 
Range: (1;15) for an extended advanced link. 
N.273 Maximum number of TL-SDU retransmissions: 

• This value is defined during the set-up of the advanced link (see AL-SETUP definition). Range: (0;7). 
N.274 Maximum number of segment retransmissions: 

• This value is defined during the set-up of the advanced link, (see AL-SETUP definition). Range: (0;15). 
N.281 Window size for TL-SDU in unacknowledged service: 

• This value is defined during the set-up of the advanced link (see AL-SETUP definition). 

Range: (1;3) for the original advanced link. 
Range: (1;15) for an extended advanced link. 
N.282 Number of repetitions for unacknowledged information: 

• This value is defined during the set-up of the advanced link (see AL-SETUP definition). Range: (0;7). 
N.293 Number of repetitions of layer 2 signalling PDU: 

• MS designer choice from range to 5. 

NOTE 2: The MAC may indicate the required number of repetitions of a particular layer 2 signalling PDU. The 

value of N.293 chosen by the MS designer applies when the MAC does not indicate the required number 
of repetitions. 

NOTE 3: It is recommended that N.293 is set to in most cases. 
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Annex B (normative): 
MAC timers and constants 

This annex lists the MAC timers and constants in the MS. 

Where indicated, a value should be chosen by the MS designer from within a given range. For other timers and 
constants, a default value is given. The default value shall be used by the MS unless it received a different value when it 
subscribed to that network. 



B.1 IVIAC timers 



Timers T.202 and T.206 are defined in terms of downlink signalling frames for the control channel on which the 
downlink message is expected. When counting downlink signalling frames, the MS should normally count all frames, 
except that: 

• on an assigned channel, the MS shall count only those downlink frames that are available for control signalling 
on that channel; note, however, that the BS may choose to send a PDU to the MS by stealing from the 
downlink TCH; 

• if the MS is transmitting traffic then the MS shall count only those downlink frames that it is required to 
monitor (according to the assigned monitoring pattern(s)) and that are available for control signalling; note, 
however, that the BS may choose to send a PDU to the MS by stealing from the downlink TCH in one of the 
monitored slots; 

NOTE 1: For a multi-slot channel, if the MS is not frequency full duplex, and if the BS assigns monitoring 

pattern(s) that the MS is not capable of following, then, when counting downlink frames, the MS counts 
only those frames containing at least one slot that it is able to monitor and that is available for control 
signalling. 

• if the MS is in minimum mode, the MS shall count only frame 18; note, however, that the BS may choose to 
send a PDU to the MS in slot 1 during frames 2 to 17; 

• on a time-shared MCCH, the MS shall count only frames reserved for this BS; note, however, that the BS may 
choose to send a PDU to the MS in one of the common frames. 

T.201 Event label inactivity time-out: 

• On the MCCH or common SCCH, default value = 30 multiframes. 

• On any assigned channel, no default upper limit. 
T.202 Fragmentation time-out: 

• Default value = 9 downlink signalling frames. 
T.205 Random access time-out: 

• MS designer choice from 5 multiframes to 60 multiframes. 
T.206 Reserved access waiting time-out: 

• Default value =18 downlink signalling frames. 
T.208 Inactivity time-out on assigned SCCH: 

• Default value = 30 multiframes. 
T.209 Inactivity time-out on traffic channel: 

• Default value =18 multiframes. 



£75/ 



1 1 28 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

T.210 Timer for returning to energy economy mode: 

• Default value = 18 TDMA frames. 

T.21 1 ACCESS-ASSIGN time-out for transmission of TCH: 

• Default value = 36 TDMA frames. 

T.212 ACCESS-ASSIGN time-out for reception of TCH: 

• Default value = 18 TDMA frames. 
T.21 3 DTX timer: 

• Default value = 18 TDMA frames. 
T.214 Stealing timer: 

• Default value = 6 uplink opportunities. 

T.21 5 Timer for traffic receive authorization if obeying channel allocation after delay: 

Default value = 18 TDMA frames. 
T.21 6 Timer for leaving assigned channel after channel replacement: 

• Default value = 2 TDMA frames. 

T.220 Timer for returning to dual watch reception cycle: 

• Default value = 18 TDMA frames. 

NOTE 2: For correct operation of the procedures, T.206 > T.202. 
T.222 Layer 2 data priority lifetime timer: 

• This value is defined by SNDCP signalling and given to the MAC in the TMC-CONFIGURE request 
primitive. 

T.223 Layer 2 data priority signalling delay timer: 

• This value is defined by SNDCP signalling and given to the MAC in the TMC-CONFIGURE request 
primitive. 

T.226 Napping timer: 

• This value is defined in the channel allocation (see channel allocation information element definition). 
T.227 Minimum scheduled access waiting time-out: 

• Default value = 9 TDMA frames. 
T.230 Link adaptation feedback time-out: 

• This value is defined when feedback is invited (see L2 -LINK-FEEDBACK-CONTROL definition). 
T.23 1 Minimum feedback interval: 

• This value may be defined when feedback is invited (see L2-LINK-FEEDBACK-CONTROL definition). 

• Otherwise, MS designer choice with T.231 > 9 TDMA frames. 
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B.2 MAC constants 

N.202 Maximum size of TM-SDU: 

• 2 632 bits (i.e. 329 octets). 

N.203 Number of timeslots without a fragment before MAC will discard an uncompleted TM-SDU: 

• Default value greater than or equal to 4. 

N.208 Number of invalid ACCESS-ASSIGN PDUs to leave assigned channel: 

• Default value = 3. 

NOTE 1 : The value of N.208 may be different on a QAM channel from the value on a 7i/4-DQPSK or 
D8PSK channel 

N.209 Quality threshold on a QAM channel: 

Assumed default value = 4. 

NOTE 2: The values of N.209 and N.210 need not be integers. 

N.210 Quahty threshold on a 7i/4-DQPSK or D8PSK channel: 

• Default value = 4. 

N.21 1 Number of invalid ACCESS-ASSIGN PDUs to stop transmission of TCH: 

• Default value = 3. 

N.212 Number of invahd ACCESS-ASSIGN PDUs to stop reception of TCH: 

• Default value = 3. 

N.213 Number of vaHd ACCESS-ASSIGN PDUs to allow reception of TCH: 

• Default value = 3. 

N.214 Number of transmissions if stealing repeats flag is set: 

• Default value = 4. 

N.215 Number of unallocated ACCESS-ASSIGN PDUs to deallocate common channel. 

• Default value = 3. 

N.223 Maximum number of transmissions of same or equivalent L2-DATA-PRIORITY message: 

• MS designer choice from range 1 to 5. 

N.23 1 Maximum number of transmissions of same or similar L2-LINK-FEEDB ACK-INFO message: 

• MS designer choice from range 1 to 5. 
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Annex C (normative): 

Mathematical definition of Frame Check Sequence (FCS) 

The FCS value corresponding to a given frame is defined by the following procedure: 

1) the first 4 octets (first 32 bits) of the frame are complemented. If there are less than 32 bits, then those bits will 
be complemented; 

2) the n bits of the frame are then considered to be the co-efficients of a polynomial M(x) of degree n - 1 ; 

32 

3) M(x) is multiplied by x and divided by G(x), producing a remainder R(x) of degree less than 32; 

4) the co-efficients of R(x) are considered to be a 32-bit sequence; 

5) the 32-bit sequence is complemented and the result is the FCS. 
The generator polynomial is defined as: 



Gix) = i+x+x' + xUx' + x' + x' + x'° + x'' + X'2 + X'^ + X'' + X'' + X'' + X'' 



(C.l) 



NOTE: There is a minor difference in the rule 1 compared to ISO/IEC 13239 [i.8] in the case when the frame 
length is less than 32 bits. 
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Annex D (informative): 

MAC scenarios for use of traffic channel 

This annex shows some examples of scenarios for use of an assigned channel for a circuit mode call. It demonstrates 
methods for using the MAC TMD-SAP procedures described in clause 23.8 and shows some possible CMCE signalling 
scenarios. 

The BS may use the protocol facilities provided for call set-up and channel usage for circuit mode calls in many 
different ways. For example: 

• early, medium or late assignment; 

• transmission, quasi-transmission or message trunking; 

• simplex or duplex calls; 

• different strategies in case of transmission errors. 

Figure Dl to figure DIO illustrate a few examples of signalling related to circuit mode calls. It should be noted that 
there are many other possible scenarios depending on the BS's methods for allocating resources. It should also be noted 
that some of the features represented here are optional. 

In the figures, * beside a BS PDU represents a channel change command. In all the examples shown, the position of any 
slot grant is on the allocated channel. 
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Figure D.I : Initial access message exchange in group call set-up procedure 
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Figure D.l illustrates a call set-up of a group call on a single cell (without presence indication). The assigned channel is 
on the main carrier, so no CLCH is needed. The D-CONNECT PDU authorizes the calling MS to start transmitting 
traffic on the assigned channel and the D-SETUP PDU authorizes the called members of the group to receive traffic. In 
this example, the BS does not grant a subslot for the calling MSs layer 2 acknowledgement to the D-CONNECT PDU, 
so the MS steals from the first traffic slot. On the downlink, the BS replaces the half slot with the Null PDU on STCH. 
The BS may send back-up D-SETUP PDUs (not shown) to the called group. 

In figure D.l, the BS instructs the calling MS to send a layer 2 acknowledgement to the D-CONNECT PDU. This is an 
optional feature. For example, the BS may choose instead to send the D-CONNECT PDU several times without 
demanding the layer 2 acknowledgement and so allowing TCH to start one half slot earlier. This general principle 
applies also to other figures in this annex. 
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Figure D.2: Initial access message exchange in group call set-up procedure 

Figure D.2 illustrates another call set-up of a group call on a single cell (without presence indication). The assigned 
channel is not on the main carrier, so the BS gives "Immediate CLCH Permission" to the calling MS with the channel 
allocation. In this example, the BS grants the second subslot (after the CLCH) for the calling MSs layer 2 
acknowledgement; the MS can then start full-slot TCH in the next slot 2. The BS also gives "Immediate CLCH 
permission" with the first D-SETUP PDU to the group members. In the example, the BS sends a back-up D-SETUP 
message on the MCCH. There is "No Immediate CLCH Permission" in the back-up message, because the calling MS 
has already started traffic transmission. 

In figure D.2, traffic from the source is not available for transmission in the first downlink slot on the allocated channel. 
The BS therefore sends C-plane STCH H- STCH on the downlink, in this case containing null C-plane signalling, until 
traffic from the source is available. 
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Group encrypted call, no presence indication, same cell, change of carrier 
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Figure D.3: End-to-end signalling for starting encryption of speech (group call) 

Figure D.3 is similar to figure D.2 except that this call uses end-to-end encryption, so the calling MS steals from the 
first traffic slot to send U-plane signalling. This message is passed on to the receiving group. 

Figure D.4 illustrates a call set-up of an individual call on a single cell (with direct call set-up). The BS checks the 
availability of the called MS before allocating a traffic channel. The assigned channel is on the main carrier, so no 
CLCH is needed. In this example, the BS sends D-CONNECT-ACK with the channel allocation to the called MS, 
authorizing it to receive traffic. However, it waits for the called MS to respond before authorizing the calling MS to 
start transmitting traffic (D-CONNECT PDU). 

In the example shown, the BS receives a layer 2 acknowledgement from the called MS in the granted subslot. If it had 
not received a PDU in the granted subslot, then it cannot know whether it was the downlink message that failed or only 
the uplink response. So it does not know whether the MS is still receiving the MCCH or whether it has moved to slot 2. 
Using the method illustrated, the BS can repeat the D-CONNECT ACK on the MCCH and also page the MS on slot 2 
until it receives a layer 2 acknowledgement on slot 2. The BS can then authorize the calling MS to transmit. 
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Individual call, direct set-up signalling, same cell, no change of carrier 
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Figure D.4: Initial access message exchange in individual call set-up procedure 

The signalling method shown in figure D.4 can be used more generally when there may be a queuing delay between 
D-CALL PROCEEDING and channel allocation. Whereas, in the case illustrated, with no queuing delay, the BS could 
have delayed the D-CALL PROCEEDING until channel allocation (replacing D-INFO). 

Alternatively to the method shown in figure D.4, the BS may send D-CONNECT to the calling IVIS with the channel 
allocation (instead of D-INFO). This method is illustrated in figure D5. It can be seen that this allows TCH to start one 
half slot earlier. However, if the called MS misses the D-CONNECT ACK PDU, it will not receive the first part of the 
traffic. Also, for repeat signalling, the BS must either use the unacknowledged service or grant a subslot on the MCCH 
(i.e. before the channel change) or delay the layer 2 acknowledgement until frame 18. 
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Individual call, direct set-up signalling, same cell, no change of carrier 
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Figure D.5: Initial access message exchange in individual call set-up procedure 



ETSl 



1136 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



Figure D.6 is similar to figure D.4, but with a change of carrier. 

Individual call, direct set-up signalling, same cell, change of carrier 
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Figure D.6: Initial access message exchange in individual call set-up procedure 
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Figure D.7 is similar to figure D.6, except that this call uses end-to-end encryption. 
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Figure D.7: End-to-end signalling for starting encryption of speech (individual call) 
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Figure D.8 shows an example of signalling at the end of an "over" in an individual call. In this example, the BS requires 
confirmation of receipt of D-TX-CEASED from both MSs. 



MS1 



End of transaction, individual call 



1 


///// 


3 


1 


m 


3 


1 


y 

2<' 


/ 3 


4 




V 


[TCH] 




V 


[STCH 


] 


Y [SCH/HU] 



MAC-Traffic 
(speech or data) 



MAC-Data 
(U-TX ceased) 



MAC-Access 
(L2 Ack) 



BS 



(D-TX ceased) 
MAC-Resource 













A 


[STCH 


] 








1 


2 


3 


1 


2 


3 


1 


2 


3 


4 




\ 


/ 


[TCH] 




V 


[STCH 


] 









MAC-Traffic 
(speech or data) 



MAC-Resource 
(D-TX ceased) 



MS2 

















(L2 Ack) 


















MAC-Access 














'^ [SCH/HU] 








1 








1 ^^ 


^ 






1 


2 


3 


4 1 


2 


3 


4 




2 


3 


4 



■> 



28 



57 



85 



113 



142 



170 



[ms] 



MSI transmission 



MS2 transmission 



Figure D.8: End of transaction sequence in circuit mode 
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Figures D.9 and D.IO show options for signalling at the start of subsequent "over" for a message trunked call. The BS 
may prefer to wait for an acknowledgement from the receiving party before giving transmit permission, as in figure D9. 
Or it may give transmit and receive permission at the same time, as in figure D.IO (risking some loss of traffic by the 
recipient). 
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Figure D.9: Start of subsequent transaction in circuit mode 
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Start of subsequent transaction in circuit mode 
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Figure D.10: Start of subsequent transaction in circuit mode 
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Annex E (normative): 

PDU encoding rules and examples 



This annex defines general PDU encoding rules and examples for some PDUs, which may require further clarification. 

E.1 PDU encoding rules for CMCE, MM and SNDCP 
PDUs 

E.1 .1 General PDU encoding rules for CMCE, MM and SNDCP 
PDUs 

The general format of the PDUs are defined in table E.1. The information element Protocol identifier is present for each 
PDU before the PDU type element although not shown in the PDU descriptions. The MLE sub-layer shall add/remove 
Protocol identifier element before sending the PDU to lower layers or passing the PDU to other layer 3 entities. 

The elements shall be transmitted in the order specified by the table with the top element being transmitted first (before 
interleaving). The content of an information element is represented by a binary value and the most significant bit of that 
binary value shall be transmitted first (before interleaving). 

Table E.1 : CMCE, MM and SNDCP PDU layout 



Information element 


Length 


Value 


Remark 


PDU type 


variable 




Dependent on the protocol entity 


Type 1 element (1) 


variable 




See definitions below 


Type 1 element (2) 


variable 




See definitions below 


etc. 


etc. 




etc. 


Type 1 element (m) 


variable 




See definitions below 


Conditional element to previous 
element 


variable 




See definitions below 


etc. 


etc. 




etc. 


Type 1 element (m+1) 


variable 




See definitions below 


etc. 


etc. 




etc. 


Type 1 element (n) 


variable 




See definitions below 


Optional bit (0-bit) 


1 





No optional type 2 or type 3/4 elements follow 


1 


Optional type 2 or type 3/4 elements follow 


Presence bit (P-bit) (1) 


1 





The type 2 element (1 ) is not present 


1 


The type 2 element (1 ) is present 


Type 2 element (1) 


variable 




See definitions below 


Presence bit (P-bit) (2) 


1 





The type 2 element (2) is not present 


1 


The type 2 element (2) is present 


Type 2 element (2) 


variable 




See definitions below 


etc. 


etc. 




etc. 


Presence bit (P-bit) (m) 


1 





The type 2 element (m) is not present 


1 


The type 2 element (m) is present 


Type 2 element (m) 


variable 




See definitions below 


Conditional element to previous 
element 


variable 




See definitions below 


etc. 


etc. 




etc. 


Presence bit (P-bit) {m+^) 


1 





The type 2 element (m+1) is not present 


1 


The type 2 element (m+1) is present 


Type 2 element (m+1) 


variable 




See definitions below 


etc. 


etc. 




etc. 


Presence bit (P-bit) (n) 


1 





The type 2 element (n) is not present 


1 


The type 2 element (n) is present 


Type 2 element (n) 


variable 




See definitions below 
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Information element 


Length 


Value 


Remark 


More bit (M-bit){1) 


1 





No type 3/4 elements follow 


1 


Type 3/4 elements follow 


Type 3 element identifier (1) 


4 




See definitions below 


Lengtii indicator (1) 


11 





Reserved 


1 to 2 047 


Length of the following type 3 Element in bits: 


Type 3 element (1) 


variable 




See definitions below 


More bit (M-bit) (2) 


1 





No more type 3/4 elements follow 


1 


More type 3/4 elements follow 


Type 3 element identifier (2) 


4 




See definitions below 


Length indicator (2) 


11 




See length indicator (1) 


Type 3 element (2) 


variable 




See definitions below 


More bit (M-bit) (3) 


1 





No more type 3/4 elements follow 


1 


More type 3/4 elements follow 


Type 4 element identifier (3) 


4 




See definitions below 


Length indicator (3) 


11 




Total length of the following type 4 Elements in bits 
(including the Number of repeated elements) 


Number of repeated elements 
(3) 


6 





Reserved 


1 to 63 


Indicates the number of repeated type 4 elements 


Type 4 sub-element (3.1) 


variable 




See definitions below 


Type 4 sub-element (3.2) 


variable 




See definitions below 


etc. 


etc. 




etc. 


Type 4 sub-element (3.n) 


variable 




See definitions below 


More bit (M-bit) (4) 


1 





No more type 3/4 elements follow 


1 


More type 3/4 elements follow 


etc. 


etc. 




etc. 


More bit (M-bit) (n) 


1 





No more type 3/4 elements follow 


1 


More type 3/4 elements follow 


Type 3 element identifier (n) 


4 




See definitions below 


Length indicator (n) 


11 




See length indicator (1) 


Type 3 element (n) 


variable 




See definitions below 


More bit (M-bit) (n+1) = 


1 





Last M-bit (Least Significant Bit (LSB) in the PDU) = 



Presence of 0-bit, P-bit and M-bit: 

The O-bit is always present straight after last type 1 element or element conditional to the last type 1 element unless 
stated otherwise in the PDU description. In case O-bit has value "0", the PDU contains no more elements; no P-bits for 
type 2 elements, no type 2 elements, no M-bits nor type 3 or type 4 elements. 

In case the O-bit has value 1, then at least one type 2, type 3 or type 4 element follows. In this case there is P-bit for 
each type 2 element which is defined for the PDU; if the type 2 element is present in the PDU then the corresponding 
P-bit has value 1, if the type 2 element is not present, then the corresponding P-bit has value 0. 

NOTE 1 : There is no P-bit before an element that is conditional to type 2 element. 

In case the O-bit has value 1, then after the last type 2 element or element that is conditional to the last type 2 element, 
or after the P-bit indicating that the last type 2 element is not present, there is always an M-bit telling whether there are 
any type 3 or type 4 elements present in the PDU. For each type 3 or type 4 element present in the PDU there is 
preceding M-bit having value 1 . After the last type 3 or type 4 element, there is always one M-bit (the last bit in the 
PDU) having value 0. 

NOTE 2: If there are type 2 element(s) present in the PDU and no type 3/4 elements are specified for the PDU, the 
M bit is present and set to "0" unless stated otherwise in the PDU description. 

NOTE 3: In case the PDU definition does not contain any type 2 elements and the PDU contains type 3 or type 4 
elements, then there is the O-bit having value 1 after the last type 1 element or element conditional to the 
last type 1 element, followed by M-bit having value 1 and then the first type 3 or type 4 element. 

NOTE 4: If there is no type 2 nor type 3 nor type 4 elements specified for the PDU the O-bit is present and set 
to "0" unless stated otherwise in the PDU description. 
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Length of the elements: 



The length of a type 1 or type 2 element or element conditional to type 1 or type 2 element is either fixed as indicated in 
the "Length" column in the PDU or the length may be indicated by the value of a preceding element to which this 
element is conditional. 

NOTE 5: A conditional element may also be present in the PDU varying times as indicated by the value of a 
preceding element to which this element is conditional. In such case the element is marked as 
"Repeatable" in the PDU. 

The length of a type 3 and type 4 element is indicated by the preceding "Length indicator" element. 

NOTE 6: Because of these PDU encoding rules, only adding of a type 3 or type 4 element can be done without 

causing backward incompatibility problems, as the decoding entity can pass unknown type 3 and type 4 
elements because their length is indicated in the PDU whereas the length of type 1 or type 2 element are 
known beforehand. 

Encoding rules for PDU: 

The element type defines the encoding rule applied to an element as follows: 

• Type 1 elements are mandatory and shall be placed within the PDU in a fixed order as specified in the PDU 
description tables. Type 1 elements shall be placed before any type 2 or type 3 elements in the PDU encoding. 
In addition the PDU may contain elements that are conditional to type 1 elements; they are present only if the 
corresponding type 1 element has specified value. These conditional elements are placed after the type 1 
elements to which they are conditional; 

• Type 2 elements are optional and shall be placed within the PDU in a fixed order as specified in the PDU 
description tables. Type 2 elements shall be placed after all type 1 elements and elements conditional to type 1 
elements, and before any type 3 elements in the PDU encoding. In addition the PDU may contain elements that 
are conditional to type 2 elements; they are present only if the corresponding type 2 element has specified 
value. These conditional elements are placed after the type 2 elements to which they are conditional; 

• Type 3 and type 4 elements are optional and shall be placed within the PDU in numerical order as specified 
within the "type 3/4 Element Identifier" element. Type 3/4 Elements shall be placed after any type 1 and type 2 
elements in the PDU encoding. Each type 3 and type 4 element shall be preceded by a "type 3/4 Element 
Identifier" element and a "Length Indicator" element in that order. In addition for each type 4 element a length 
indicator shall be followed by the "Number of repeated elements" information element. 

NOTE 7: For presentation purposes a set of information elements can be defined as an information element. The set 
of information sub-elements may contain also optional or conditional elements and also elements 
consisting of set of sub-elements. The set is encoded into the PDU as if it were a single information 
element of the indicated type. 
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The following rules shall apply for decoding of the PDU: 

DO for all Type 1 elements 
DECODE Type 1 element 

WHILE conditional elements to the type 1 element 

DECODE conditional element 
END WHILE 
END DO 
DECODE 0-bit 

IF 0-bit set to 'No Optional Elements present' 
THEN END of PDU decoding 
ELSE 

DO for all possible Type 2 elements 
DECODE P-bit 
IF P-bit set to 'Present' 

THEN DECODE Type 2 element AND 

WHILE conditional elements to the type 2 element 

DECODE conditional element 
END WHILE 
END DO 

WHILE M-bit set to 'More Type 3/4 elements follows' 
IF element is a Type 4 element 

THEN DECODE Number of repeated elements 
WHILE more type 4 sub-elements 

DECODE Type 4 sub-element 
END WHILE 
ELSE 

DECODE Type 3 element 
END IF 
END WHILE 
END of PDU decoding. 

The encoding rules for sub-elements: 

• in case the PDU information element or sub-element definition contains no "Type" column, the sub-elements 
of the element/sub-element are all considered to be of type 1 ; 

• type 1 element or type 1 sub-element can contain only type 1 sub-elements and conditional elements to type 1 
element/sub-element; 

• type 2 element or type 2 sub-element can contain only type 1 sub-elements and conditional elements to type 1 
element/sub-element; 

• element conditional to type 1 or type 2 element or sub-element can contain only type 1 sub-elements and 
conditional elements to type 1 element/sub-element; 

NOTE 8: As no optional elements are specified for the type 1 or type 2 element/sub-element, there is no O-bit (nor 
M-bit) after the last type 1 sub-element or conditional element. 

• type 3 or type 4 element or sub-element can contain sub-elements which can be one of type 1, 2, 3 and 4. In 
case the type 3 or type 4 element/sub-element definition does not contain optional elements, there is no O-bit 
after the type 1 sub-elements; 

• in case type 3 or type 4 element/sub-element definition contains optional type 2 or type 3 elements, there shall 
be an O-bit indicating whether the type 3/4 element/sub-element contains any optional elements: 

in case the type 3 or type 4 element/sub-element contains no optional elements, the O-bit is set to value 
"no optional elements follow" and no other information shall be included to the type 3 or type 4 
element/sub-element; 
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in case the type 3 or type 4 element/sub-element contains optional elements (either type 2 or type 3 or 
type 4) the O-bit is set to value "optional elements follow" and a P-bit shall be set for each type 2 
optional element (if any defined) indicating presence of that element. The P-bit shall indicate either 
"type 2 element present" or "type 2 element not present": 

■ in case the element/sub-element definition does not contain any type 3 or type 4 elements there 
shall be no M-bit after the last type 2 element or conditional element or the P-bit indicating that the 
last type 2 element is not present. 

■ in case the type 3/4 element/sub-element definition contains type 3/4 elements, there shall be 

a M-bit after the last type 2 element or conditional element or P-bit indicating that last optional 
type 2 element is not present, indicating whether the element/sub-element contains any type 3/4 
elements. The type 3 and type 4 sub-elements are coded similarly as type 3 and type 4 PDU 
information elements, i.e. type 3 and type 4 sub-element shall be preceded by a "type 3/4 Element 
Identifier" element and a "Length Indicator" element in that order. In addition in the type 4 
sub-element a length indicator shall be followed by the "Number of repeated elements" information 
element. A further M-bit shall follow each Type 3/4 sub-element to indicate either "type 3/4 
element to follow" or "no type 3/4 element to follow". After the last type 3/4 sub-element included 
the M-bit shall be set to "0" to indicate "no type 3/4 element to follow" in this sub-element. 

in case the information element/sub-element contains one or more type 3 elements but no 
type 2 elements are specified for the element/sub-element, an M-bit (having value "type 3/4 
elements to follow") shall follow the O-bit (having value "optional elements to follow") 
placed after the last type 1 element. 

in case the element/sub-element contains no type 3/4 elements but contains type 2 elements 
there shall be one M-bit bit indicating "no type 3/4 elements to follow" after the last type 2 
element or P-bit indicating that last optional type 2 element is not present as the last bit in the 
type 3/4 element. 

The C/O/M column indicates Inow tine presence of an information element is controlled in the PDU or 
element/sub-element: 

M: Mandatory information element is always present (mandatory) in the main PDU level and is always present in 
a sub-element, when the sub-element itself is present. The type of mandatory element is type 1; 

O: Optional information element may be present in the PDU. The protocol state or an implementation choice 
defines when it is present or not. The type of optional element is either type 2 or type 3 or type 4; 

C: Conditional information element is present as defined in the PDU or element/sub-element description. The 
presence depends on the value of another preceding information element. If the information element on which 
the conditional information element is conditional is not present then also the conditional information element 
is not present. The conditional information element may be also repeated as many times as indicated by 
a preceding information element. 
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E.1 .2 PDU encoding examples for CMCE PDUs 

Tables E.2 to E.6 present examples of proper CMCE PDU encoding in specific cases. 

Table E.2: D-FACILITY PDU with two SS-PDUs 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 




M 


CMCE 


PDU Type 


5 




M 


D-FACILITY 


Number of SS PDUs 


4 




M 


2 




Length indicator 


11 




M 


variable 




SS-PDU contents 


variable 




C 


variable 




Length indicator 


11 




M 


variable 




SS-PDU contents 


variable 




C 


variable 


Optional elements present? 


1 


0-bit 




(no optional elements present in 
D-FACILITY PDU) 


NOTE: When the U/D-FACILITY PDU contains more than a single SS-PDU it is a collection of SS-PDUs 

which are encoded independently of each other. Each SS-PDU may contain any type of information 
elements as defined for the SS-PDU. 


Table E.3: D-FACILITY PDU with 


'SS not supported 


" acknowledgement 


Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 




M 


CMCE 


PDU Type 


5 




M 


D-FACILITY 


Number of SS PDUs 


4 




M 


1 


Length indicator 


11 




M 


12 


SS-PDU contents 


variable 




C 


12, See next 3 elements 




SS-Type 


6 




M 


SS-DGNA 




SS-PDU Type 


5 




M 


SS not supported 




Optional elements present? 


1 


0-bit 




(for SS not supported PDU) 


Optional elements present? 


1 


0-bit 
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Table E.4: D-FACILITY with SS-DGNA ASSIGN PDU 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 




M 


CMCE 


PDU Type 


5 




M 


D-FAGILITY 


Number of SS PDUs 


4 




M 


1 


Length indicator 


11 




M 


147 


SS-PDU contents 


147 







See next 20 rows 




SS type 


6 




M 


SS-DGNA 




SS-DGNA PDU type 


5 




M 


ASSIGN 




Number of groups 


5 




M 


2 (Group assignments) 




Group assignment (first) 


82 







See next 1 5 rows 






1 


Group SSI 


24 




M 


Any 




Group extension present 


1 




M 


Group extension present 




Group extension 


24 




C 


Any 




Group identity attachment mode 


3 


1 


M 


Any 




Optional elements present? 


1 


0-bit 




1 




P-bit for Glass of usage element 


1 


P-bit 




1 






Glass of usage 


3 


2 





Any 






P-bit for Mnemonic group name 
element 


1 


P-bit 




1 






Mnemonic group name 


39 


2 





See next three elements. 






Text coding scheme 


7 


1 


M 


Latin-1 (8-bit characters) 






Length of mnemonic 
group name character 
string 


8 


1 


M 


24 




Mnemonic group name 
character string 


24 







"EPT" (=3x8) 






P-bit for Length of security 
related information element 


1 


P-bit 









Length of additional group 
information element 


1 


P-bit 









P-bit for (V)GSSI 


1 


P-bit 





















Group assignment (second) 


29 


1 





See next 4 rows 




2 


Group SSI 


24 


1 


M 


Any 




Group extension present 


1 


1 


M 


No group extension present 




Group identity attachment mode 


3 


1 


M 


Any 






Optional elements present? 


1 


0-bit 




(in this Group assignment) 




Acknowledgement requested from 
affected user(s) 


1 


1 


M 


Any 




Optional elements present? 


1 


0-bit 




(for SS-DGNA ASSIGN PDU) 


Optional elements present? 


1 


0-bit 




(for D-FACILITY PDU) 


NOTE: The IVInemonic name encoding reqL 
mnemonic group name character st 
optional as the length allows to by-p 


ires that ti- 
ring inform 
ass the na 


e receivi 
ation ele 
me. 


ng entity is c 
Tient. The de 


apable to understand the Length of 
coding of the mnemonic name is 



Table E.5: U-INFO PDU with DTMF element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


CMCE 


PDU Type 


5 


1 


M 


U-INFO 


Poll response 


1 


1 


M 





Optional elements present? 


1 


0-bit 




1 


P-bit for Modify element 


1 


P-bit 







Type 3 / 4 elements to follow 


1 


M-bit 




1 




Type 3/4 element identifier 


4 




M 


DTMF 




Length indicator 


11 




M 


11 




DTMF type 


3 




M 


DTMF tone start 




DTMF digit 


4 




M 


1st digit 




DTMF digit 


4 




M 


2nd digit 


Type 3 / 4 elements to follow 


1 


M-bit 
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Table E.6: U-STATUS PDU with External subscriber number element 



Information Element 


Length 


Type 


C/O/IM 


Value 


Protocol discriminator 


3 


1 


M 


CMCE 


PDU Type 


5 


1 


M 


U-STATUS 


Area selection 


4 


1 


M 


Any 


Called party type identifier 


2 


1 


M 


SSI 


Called party SSI 


24 




C 


Any gateway 


Pre-coded status 


16 


1 


M 


Any 


Optional elements present? 


1 


0-bit 




1 


Type 3/4 elements to follow 


1 


M-bit 




1 




Type 3/4 element identifier 


4 


1 


M 


External subscriber number 




Length indicator 


11 


1 


M 


28 




External subscriber number digit 


4 


1 


M 


1st digit 




External subscriber number digit 


4 


1 


M 


2nd digit 




External subscriber number digit 


4 


1 


M 


3rd digit 




External subscriber number digit 


4 


1 


M 


4th digit 




External subscriber number digit 


4 


1 


M 


5th digit 




External subscriber number digit 


4 


1 


M 


6th digit 




External subscriber number digit 


4 


1 


M 


7th digit 


Type 3/4 elements to follow 


1 


M-bit 








E.1 .3 PDU encoding examples for MM PDUs 

Tables E.7 to E.12 present examples of proper MM PDU encoding in specific cases. 

Table E.7: D-ATT AC/DETACH GROUP IDENTITY PDU 



Information Element 


Length 


Type 


C/O/IM 


Value 


Protocol discriminator 


3 


1 


M 


MM 


PDU Type 


4 


1 


M 


D-ATTACH / DETACH GROUP 
IDENTITY 


Group identity report 




1 


M 


No report request 


Group identity acknowledgement request 




1 


M 


Any 


Group identity attach/detach mode 




1 


M 


Any 


Optional elements present? 




0-bit 




1 


Type 3/4 elements to follow 




M-bit 




1 




Type 3/4 element identifier 


4 


1 


M 


Group identity downlink 




Length indicator 


11 


1 


M 


67 




Number of repeated elements 


6 


1 


M 


2 






1 


Group identity attach/detach 
type identifier 


1 


1 


M 


Attachment 




Group identity attachment 


5 




C 


See next 2 rows 








Group identity attachment 
lifetime 


2 


1 


M 


Any 




Class of usage 


3 


1 


M 


Any 






Group identity address type 


2 


1 


M 


GSSI 




GSSI 


24 




C 


Any 




2 


Group identity attach/detach 
type identifier 


1 


1 


M 


Detachment 




Group identity detachment 
downlink 


2 




C 


Any 




Group identity address type 


2 


1 


M 


GSSI 




GSSI 


24 




C 


Any 


Type 3/4 elements to follow? 


1 


M-bit 
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Table E.8: D-LOCATION UPDATE ACCEPT PDU without optional elements 



Information Element 


Length 


Type 


C/O/IM 


Value 


Protocol discriminator 


3 


1 


M 


MM 


PDU Type 


4 


1 


M 


D-LOCATION UPDATE ACCEPT 


Location update accept type 


3 


1 


M 


Any 


Optional elements present? 


1 


0-bit 








Table E.9: D-LOCATION UPDATE ACCEPT PDU with optional Type 4 elements 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MM 


PDU Type 


4 


1 


M 


D-LOCATION UPDATE ACCEPT 


Location update accept type 


3 


1 


M 


Any 


Optional elements present? 


1 


0-bit 




1 


P-bit for SSI element 


1 


P-bit 







P-bit for Address extension element 


1 


P-bit 







P-bit for Subscriber class element 


1 


P-bit 




1 


Subscriber class 


16 


2 





Any 


P-bit for Energy saving information 
element 


1 


P-bit 







P-bit for SCCH information and 
distribution on 18th frame element 


1 


P-bit 







Type 3 / 4 elements to follow 


1 


M-bit 




1 




Type 3/4 element identifier 


4 


1 


M 


New registered area 




Length indicator 


11 


1 


M 


42 




Number of repeated elements 


6 


1 


M 


2 






1 


LA timer 


3 


1 


M 


Any 




LA 


14 


1 


M 


Any 




Optional elements present? 


1 


0-bit 









2 


LA timer 


3 


1 


M 


Any 




LA 


14 


1 


M 


Any 




Optional elements present? 


1 


0-bit 







Type 3/4 elements to follow 


1 


M-bit 




1 




Type 3/4 element identifier 


4 


1 


M 


Group identity location accept 




Length indicator 


11 


1 


M 


55 




Group identity accept/reject 


1 


1 


M 


Any 




Reserved 


1 


1 


M 


Any 




Optional elements present? 


1 


0-bit 




1 




Type 3/4 elements to follow 


1 


M-bit 




1 






Type 3/4 element identifier 


4 


1 


M 


Group identity downlink 




Length indicator 


11 


1 


M 


35 




Number of repeated elements 


6 


1 


M 


1 






1 


Group identity 
attach/detach type identifier 


1 


1 


M 


Detachment 




Group identity detachment 
downlink 


2 




C 


Any 




Group identity address type 


2 


1 


M 


GSSI 






GSSI 


24 




C 


Any 




Type 3/4 elements to follow? 


1 


M-bit 




(no more elements inside Group 
identity location accept element) 


Type 3/4 elements to follow? 


1 


m-bit 




(no more elements in the D- 
LOCATION UPDATE ACCEPT PDU) 
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Table E.10: U-LOCATION UPDATE DEMAND PDU without optional elements 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 




M 


MM 


PDU Type 


4 




M 


U-LOCATION UPDATE DEMAND 


Location update type 


3 




M 


Any 


Request to append LA 


1 




M 


Any 


Cipher control 


1 




M 


1 


Ciphering parameters 


10 




C 


Any 


Optional elements present? 


1 


0-bit 







Table E.11 : U-LOCATION UPDATE DEMAND PDU with optional Type 2 elements 


Information Element 


Length 


Type 


COM 


Value 


Protocol discriminator 


3 




M 


MM 


PDU Type 


4 




M 


U-LOCATION UPDATE DEMAND 


Location update type 


3 




M 


Any 


Request to append LA 


1 




M 


Any 


Cipher control 


1 




M 





Optional elements present? 


1 


0-bit 




1 


P-bit for Class of IVIS 


1 


P-bit 




1 




Class of IVIS 


24 


2 





Any 


P-bit for Energy saving mode 


1 


P-bit 




1 


Energy saving mode 


3 


2 





Any 


P-bit for LA information 


1 


P-bit 




1 




Location Area (LA) 


14 


1 




Any 




Zero-bit 


1 


1 







P-bit for SSI 


1 


P-bit 







P-bit for Address extension 


1 


P-bit 







Type 3/4 elements present? 


1 


M-bit 
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Table E.12: U-LOCATION UPDATE DEMAND PDU with optional Type 4 element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 




M 


MM 


PDU Type 


4 




M 


U-LOCATION UPDATE DEMAND 


Location update type 


3 




M 


Any 


Request to append LA 


1 




M 


Any 


Cipher control 


1 




M 





Optional elements present? 


1 


0-bit 




1 


P-bit for Class of IVIS 


1 


P-bit 







P-bit for Energy saving mode 


1 


P-bit 







P-bit for LA information 


1 


P-bit 







P-bit for SSI 


1 


P-bit 







P-bit for Address extension 


1 


P-bit 







Type 3/4 elements present? 


1 


M-bit 




1 




Type 3/4 element identifier 


4 


1 


M 


Group identity location demand 




Length indicator 


11 


1 


M 


86 




Reserved 


1 


1 


M 


Any 




Group identity attach/detach mode 


1 


1 


M 


Any 




Optional elements present? 


1 


0-bit 




1 




Type 3/4 elements present 


1 


M-bit 




1 






Type 3/4 element identifier 


4 


1 


M 


Group identity uplink 




Length indicator 


11 


1 


M 


66 




Number of repeated elements 


6 


1 


M 


2 






1 


Group identity 
attach/detach type identifier 


1 


1 


M 


Attachment 




Class of usage 


3 




C 


Any 




Group identity address type 


2 


1 


M 


GSSI 




GSSI 


24 




C 


Any 




2 


Group identity 
attach/detach type identifier 


1 


1 


M 


Attachment 




Class of usage 


3 




C 


Any 




Group identity address type 


2 


1 


M 


GSSI 






GSSI 


24 




C 


Any 




Type 3/4 elements to follow? 


1 


M-bit 




(no more elements inside Group 
identity uplink element) 


Type 3/4 elements to follow? 


1 


M-bit 




(no more elements in the U- 
LOCATION UPDATE DEMAND PDU) 
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E.2 PDU encoding rules for MLE PDUs 
E.2.1 General PDU encoding rules for MLE PDUs 

The general format of the MLE protocol PDU is defined according to table E. 13. 

The elements shall be transmitted in the order specified by the table with the top element being transmitted first (before 
interleaving). The content of an information element is represented by a binary value and the most significant bit of that 
binary value shall be transmitted first (before interleaving). 

Table E.13: MLE protocol PDU layout 



Information element 


Length 


Value 


Remark 


Protocol discriminator 


3 


IOI2 


Specifies an MLE protocol PDU 


PDU type 


3 




Specifies the particular MLE protocol PDU 


Type 1 element (1) 


variable 




See element definition for length and values 


Type 1 element (2) 


variable 




See element definition for length and values 


etc. 


etc. 




etc. 


Type 1 element (m) 


variable 




See element definition for length and values 


Conditional element to 
previous element 


variable 




See element definition for length and values 


Type 1 element (m+1) 


variable 




See element definition for length and values 


etc. 


etc. 




etc. 


Type 1 element (n) 


variable 




See element definition for length and values 


Optional bit (0-bit) 


1 





No type 2 elements follow 


1 


Type 2 elements follow 


Presence bit (P-bit) (1) 


1 





The type 2 element (1) is not present 


1 


The type 2 element (1) is present 


Type 2 element (1) 


variable 




See element definition for length and values 


Presence bit (P-bit) (2) 


1 





The type 2 element (2) is not present 


1 


The type 2 element (2) is present 


Type 2 element (2) 


variable 




See element definition for length and values 


etc. 


etc. 




etc. 


Presence bit (P-bit) (n) 


1 





The type 2 element (n) is not present 


1 


The type 2 element (n) is present 


Type 2 element (n) 


variable 




See element definition for length and values 


Conditional element to 
previous element 


variable 




See element definition for length and values 


etc. 


etc. 




etc. 


SDU 


variable 


variable 


Encoded as nominated CMCE or MM PDU except 
protocol discriminator element is not present 


NOTE: The optional SDU information element is not preceded by a P-bit for the SDU. 



Presence of 0-bit and P-bit: 

The O-bit is always present straight after last type 1 element unless stated otherwise in the PDU description. Also when 
the no type 2 elements are defined for the PDU, the O-bit shall be present and set equal to "0", unless stated otherwise 
in the PDU description. 

In case O-bit has value "0", the PDU contains no type 2 elements; no P-bits for type 2 elements and no type 2 elements. 

In case the O-bit has value 1, then at least one type 2 element follows. In this case there is P-bit for each type 2 element 
which is defined for the PDU; if the type 2 element is present in the PDU then the corresponding P-bit has value 1, if 
the type 2 element is not present, then the corresponding P-bit has value 0. 

NOTE 1 : There is no P-bit before an element that is conditional to another element. 

NOTE 2: The PDU can contain further information after O-bit even when it is set to value "0"; the PDU can contain 
an SDU also in case the PDU does not contain any type 2 elements (the O-bit is set to "0"). 
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Length of the elements: 



The length of a type 1 or type 2 element is either fixed as indicated in the "Length" column in the PDU or variable, refer 
to note 4. The length of an element conditional to type 1 or type 2 element is either fixed as indicated in the "Length" 
column in the PDU or the length may be indicated by the value of a preceding element to which this element is 
conditional. 

NOTE 3: A conditional element may also be present in the PDU varying times as indicated by the value of 
a preceding element to which this element is conditional. In such case the element is marked as 
"Repeatable" in the PDU. 

Encoding rules for PDU: 

• elements of type 1 are mandatory and shall be placed within the PDU in fixed order as specified in the PDU 
description tables. The type 1 elements shall be placed before any type 2 elements in the PDU encoding. 

In addition the PDU may contain elements that are conditional to type 1 elements; they are present only if the 
corresponding type 1 element has specified value. These conditional elements are placed after the type 1 
elements to which they are conditional; 

• elements of type 2 are optional and shall be placed within the PDU in fixed order as specified in the PDU 
description tables. In addition the PDU may contain elements that are conditional to type 2 elements; they are 
present only if the corresponding type 2 element is present and has specified value. These conditional elements 
are placed after the type 2 element to which they are conditional; 

• elements of type SDU are placed as the last element at the end of the PDU. There is no preceding bit for the 
SDU element, the length of the whole PDU as indicated in the MAC header defines whether the element is 
present in the PDU or not. 

NOTE 4: For presentation purposes a set of information elements can be defined as an information element. The set 
of information sub-elements may contain also optional or conditional elements and also elements 
consisting of set of sub-elements. The set is encoded into the PDU as if it were a single information 
element of the indicated type. If the information element is a set of information elements that contain 
either a variable number of conditional elements or optional elements then the length is marked to be 
variable. 

The following rules shall apply for decoding of an MLE PDU: 

DO for all Type 1 elements 
DECODE Type 1 Element 

WHILE conditional elements to the type 1 element 

DECODE conditional element 
END WHILE ; 
END DO; 

IF explicitly defined that the PDU shall not contain an 0-bit 
THEN END of PDU encoding; 
ELSE 

DECODE 0-bit 

IF 0-bit set to "Type 2 elements follow" 
DO for all possible type 2 elements 
DECODE P-bit 

IF P-bit set to "Present", decode type 2 element 
WHILE conditional element to the type 2 element 

DECODE indicated conditional element 
END WHILE; 
END IF; 
END DO; 
END IF; 
IF SDU present, decode SDU 
END ELSE. 

The encoding rules for elements and sub-elements: 



• 



in case the PDU information element or sub-element definition contains no "Type" column, the element/sub- 
element is considered to be of type 1 ; 

an element or sub-element may contain a set of information elements, and any individual information element 
in that set may be followed immediately by conditional elements to that individual information element; 
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NOTE 5: When no optional elements are specified for the type 1 or type 2 elements/sub-element, there is no O-bit 
after the last type 1 sub-element. 

• a conditional information element may contain type 1 and type 2 sub-elements. In the case that at least one 
type 2 element is specified for the conditional element, there shall be an O-bit indicating whether the element 
contains any optional type 2 elements: 

in case no optional type 2 elements are present in the element, the O-bit shall be set to value "no optional 
elements follow"; 

in case at least one optional type 2 element is present in the element, the O-bit shall be set to value 
"optional elements follow" and a P-bit shall be set for each type 2 sub-element specified for the 
conditional element to indicate presence of that element. The P-bit shall indicate either "type 2 element 
present" or "type 2 element not present". 

NOTE 6: As no type 3 or type 4 sub-elements are specified for the conditional elements, there is no M-bit after the 
last type 2 element or P-bit indicating that the last optional type 2 element is not present. 

The following rules shall apply for decoding of information element containing a set of information elements: 

DO for all Type 1 elements 
DECODE Type 1 Element 

WHILE conditional elements to the type 1 element 

DECODE conditional element 
END WHILE; 
END DO; 

IF no optional information element is defined for the set of information elements 
THEN END of the set of information element encoding; 
ELSE 

DECODE O-bit 

IF O-bit set to "Type 2 elements follow" 
DO for all possible type 2 elements 
DECODE P-bit 

IF P-bit set to "Present", decode type 2 element 
WHILE conditional element to the type 2 element 

DECODE indicated conditional element 
END WHILE; 
END IF; 
END DO; 
END IF; 
END ELSE; 
END 

The C/O/M column indicates how the presence of an information element is controlled in the PDU or 
element/sub-element: 

M: Mandatory information element is always present (mandatory) in the main PDU level and is always present in 
a sub-element, when the sub-element itself is present. The type of mandatory element is type 1; 

O: Optional information element may be present in the PDU. The protocol state or an implementation choice 
defines when it is present or not. The type of optional element is type 2; 

C: Conditional information element is present as defined in the PDU description. The presence depends on the 
value of another preceding information element. If the information element on which the conditional 
information element is conditional is not present then also the conditional information element is not present. 
The conditional information element may be also repeated as many times as indicated by a preceding 
information element. 
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E.2.2 PDU encoding examples for MLE PDUs 

Tables E.14 to E.27 present examples of proper MLE PDU encoding in specific cases. 

Table E.14: D-NWRK-BROADCAST PDU with no neighbour cell information elements 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-NWRK-BROADCAST 


Cell re-select parameters 


16 


1 


M 


Any 


Cell service level 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 








Table E.15: D-NWRK-BROADCAST PDU with " No neighbour cell information available" indication 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-NWRK-BROADCAST 


Cell re-select parameters 


16 


1 


M 


Any 


Cell service level 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 




1 


P-bit for TETRA network time element 


1 


P-bit 







P-bit for Number of neighbour cells 


1 


P-bit 




1 




Number of Neighbour cells element 


3 


2 





"No neighbour cell information 
available" 
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Table E.I 6: D-NWRK-BROADCAST PDU with 2 neighbour cell information elements 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-NWRK-BROADCAST 


Cell re-select parameters 


16 


1 


M 


Any 


Cell service level 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 




1 


P-bit for TETRA network time element 


1 


P-bit 







P-bit for Number of neighbour cells 


1 


P-bit 




1 




Number of Neighbour cells element 


3 


2 





2 




Neighbour cell information (first) 


23 




C 


See next 6 rows 






1 


Cell identifier 


5 


1 


M 


Any except 




Announced cell reselection 
types supported 


2 


1 


M 


Any 




Neighbour cell synchronized 


1 


1 


M 


Any 




Cell service level 


2 


1 


M 


Any 




IVIain carrier number 


12 


1 


M 


Any 






Optional elements present? 


1 


0-bit 







Neighbour cell information (second) 


47 




C 


See next 17 rows. 




2 


Cell identifier 


5 


1 


M 


Any except 




Announced cell reselection 
types supported 


2 


1 


M 


Any 




Neighbour cell synchronized 


1 


1 


M 


Any 




Cell service level 


2 


1 


M 


Any 




IVIain carrier number 


12 


1 


M 


Any 




Optional elements present? 


1 


0-bit 




1 




P-bit for IVIain carrier number 
extension element 


1 


P-bit 









P-bit for MCC element 


1 


P-bit 









P-bit for IVINC element 


1 


P-bit 









P-bit for LA element 


1 


P-bit 




1 






LA element 


14 


2 





Any 






P-bit for Maximum MS transmit 
power 


1 


P-bit 









P-bit for Minimum RX access 
level 


1 


P-bit 









P-bit for Subscriber class 


1 


P-bit 









P-bit for BS Service details 


1 


P-bit 









P-bit for Timeshare cell 
information 


1 


P-bit 









P-bit for TDMA frame offset 


1 


P-bit 








Table E.17: D-NEW CELL PDU without SDU element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-NEW CELL 


Channel command valid 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 








Table E.18: D-NEW CELL PDU with SDU (D-LOCATION UPDATE ACCEPT PDU) element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-NEW CELL 


Channel command valid 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 









PDU Type 


4 


1 


M 


D-LOCATION UPDATE ACCEPT 




Location update accept type 


3 


1 


M 


Any 




Optional elements present? 


1 


0-bit 
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Table E.19: D-PREPARE FAIL PDU without SDU element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-PREPARE FAIL 


Fail cause 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 








Table E:20: D-PREPARE FAIL PDU with SDU (D-LOCATION UPDATE REJECT PDU) element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-PREPARE FAIL 


Fail cause 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 









PDU Type 


4 


1 


M 


D-LOCATION UPDATE REJECT 




Location update type 


3 


1 


M 


Any 




Reject cause 


5 


1 


M 


Any 




Cipher control 


1 


1 


M 







Optional elements present? 


1 


0-bit 








Table E.21 : D-RESTORE ACK PDU with SDU (D-CALL RESTORE PDU) element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-RESTORE ACK 


Optional elements present? 


1 


0-bit 









PDU Type 


5 


1 


M 


D-CALL RESTORE 




Call identifier 


14 


1 


M 


Any 




Transmission grant 


2 


1 


M 


Any 




Transmission request permission 


1 


1 


M 


Any 




Reset call time-out timer (T31 0) 


1 


1 


M 


Any 




Optional elements present? 


1 


0-bit 








Table E.22: D-RESTORE FAIL PDU 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


D-RESTORE FAIL 


Fail cause 


2 


1 


M 


Any 


Optional elements present? 


1 


0-bit 








Table E.23: U-PREPARE PDU without Cell identifier element and without SDU element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


U-PREPARE 


Optional elements present? 


1 


0-bit 








Table E.24: U-PREPARE PDU with Cell identifier element and without SDU element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


U-PREPARE 


Optional elements present? 


1 


0-bit 




1 


P-bit for Cell identifier element 


1 


P-bit 




1 


Cell identifier 


5 


2 


M 


Any 
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Table E.25: U-PREPARE PDU with SDU (U-LOCATION UPDATE DEMAND PDU) element 



Information Element 


Length 


Type 


C/O/IM 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


U-PREPARE 


Optional elements present? 


1 


0-bit 




1 


P-bit for Cell identifier element 


1 


P-bit 




1 




Cell identifier 


5 


2 


M 


Any 




PDU Type 


4 


1 


M 


U-LOCATION UPDATE DEMAND 




Location update type 


3 


1 


M 


Call restoration roaming location 
updating 




Request to append LA 


1 


1 


M 


Any 




Cipher control 


1 


1 


M 







Optional elements present? 


1 


0-bit 




1 




P-bit for Class of MS 


1 


P-bit 









P-bit for Energy saving mode 


1 


P-bit 




1 






Energy saving mode 


3 


2 





Any 


P-bit for LA information 


1 


P-bit 




1 




Location area (LA) 


14 


1 


M 


Any 


Optional elements present? 


1 


0-bit 









P-bit for SSI 


1 


P-bit 









P-bit for Address extension 


1 


P-bit 









IVI-bit for Type 3 elements 


1 


M-bit 








Table E.26: U-RESTORE PDU with optional LA element, 
U-CALL RESTORE PDU does not contain type 3 elements 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


U-RESTORE 


Optional elements present? 


1 


0-bit 




1 


P-bit for MCC element 


1 


P-bit 




1 


P-bit for MNC element 


1 


P-bit 




1 


P-bit for LA element 


1 


P-bit 




1 




LA element 


14 


2 





Any 




PDU Type 


5 


1 


M 


U-CALL RESTORE 




Call identifier 


14 


1 


M 


Any 




Request to transmit/send data 


1 


1 


M 


Any 




Other party type identifier 


2 


1 


M 


SSI 




Other party SSI 


24 




C 


Any 




Optional elements present? 


1 


0-bit 




1 




P-bit for Basic service information 
element 


1 


P-bit 




1 




Basic service information element 


8 


2 


M 


Any 


M-bit (for Type 3 elements) 


1 


M-bit 
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Table E.27: U-RESTORE PDU without optional element, 
U-CALL RESTORE PDU contains type 3 element 



Information Element 


Length 


Type 


C/O/M 


Value 


Protocol discriminator 


3 


1 


M 


MLE 


PDU Type 


3 


1 


M 


U-RESTORE 


Optional elements present? 


1 


0-bit 









PDU Type 


5 


1 


M 


U-CALL RESTORE 




Call identifier 


14 


1 


M 


Any 




Request to transmit/send data 


1 


1 


M 


Any 




Other party type identifier 


2 


1 


M 


SSI 




Other party SSI 


24 




C 


Any 




Optional elements present? 


1 


0-bit 




1 




P-bit for Basic service information 
element 


1 


P-bit 




1 




Basic service information element 


8 


2 


M 


Any 


IVI-bit (for Type 3 elements) 


1 


M-bit 




1 




Type 3 element identifier 


4 


1 


M 


Facility or Proprietary 




Length indicator 


11 


1 


M 


N 






Type 3 element 


n 


1 


M 


Any 


M-bit (for Type 3 elements) 


1 


M-bit 
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Annex F (normative): 

TETRA frequency bands, duplex spacings and channel 

numbering 

The usage of the TETRA frequency bands, duplex spacings and channel numbering shall be as defined in 
TS 100 392-15 [18]. 
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Annex G (normative): 

TETRA group management scenarios 

TETRA group management scenarios define how group management PDUs shall be encoded in the presented scenarios. 



G.1 General requirements 

The requirements are presented as a list to facilitate an easier referencing. 

1) The structure of the D/U-ATTACH DETACH GROUP IDENTITY PDUs and U/D-ATTACH DETACH 
GROUP IDENTITY ACK PDUs is defined in clause 16.9 and the PDU encoding in annex E. 

The in the Group identity uplink element as defined in clause 16.10.15 should have the values as defined 
in tabled. 

Table G.I : Group identity uplinl< information values 



Location 
scenario 


MS location 


Group identity 
address type 


1a) 


On home system 


OO2 


1b) 


On foreign system and SwMI has not previously allocated VGSSI 


OI2 


1c) 


On foreign system and SwMI has previously allocated VGSSI (for example, if 
the MS wishes to detach a group) 


IO2 



The in the Group identity downlink element as defined in clause 16.10.15 should have the values as 
defined in table G.2. 

Table G.2: Group identity downlink information values 



Location 
scenario 


MS location 


Group identity 
address type 


2a 


On home system 


OO2 


2b) 


On foreign system (SwMI initiated attachment) 


II2 


2c) i 


On foreign system (response to lb) above - acceptance of attachment 


II2 


2c) ii 


On foreign system (response to lb) above - rejection of attachment 


OI2 


2d) 


On foreign system (response to 1c) above, same VGSSI) 


IO2 


2e) 


On foreign system and the foreign SwMI wishes to allocate a new VGSSI to 
an existing GTSI which has been allocated a VGSSI (i.e. the new VGSSI 
replaces the existing VGSSI) 


II2 


2f) 


On foreign system (response to group report, SwMI has previously allocated 
VGSSI to MS) 


II2 



2) New group attachments/detachments cannot be mixed with the acknowledgements to requested group 
attachments/detachments contained in the "Group identity location accept" element of the D-LOCATION 
UPDATE ACCEPT PDU or the D/U-ATTACH / DETACH GROUP IDENTITY ACK PDUs. If the 
acknowledgement to the group attachment/ detachment request contains a group or a number of groups, those 
groups shall be the complete set or a subset of the group(s) in the request. 

3) The "Group identity attach/detach mode" element of the D -ATTACH/DETACH GROUP IDENTITY ACK 
PDU and the "Group identity attach/detach mode" element of the "Group identity location accept" element of 
the D-LOCATION UPDATE ACCEPT PDU are to be marked "Reserved". 

4) The MS shall not reject a SwMI-requested detachment; the SwMI may reject a MS-requested detachment, 
refer to scenario 5 (7). 
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5) Rejection of attachment is equivalent to acceptance of detachment: the group is detached. Rejection of 
detachment is equivalent to acceptance of attachment (subject to the restriction described in requirement 4): 
the group is attached. 

In the following set of rules, "requester" refers to the sender of the D/U- ATTACH DETACH GROUP 
IDENTITY PDU and "responder" refers to the sender of the U/D-ATTACH DETACH GROUP 
IDENTITY ACK PDU. 

6) A value of "0" (Attachment/detachment accepted) in the "Group identity accept/reject" element (D-ATTACH 
DETACH GROUP IDENTITY ACK PDU) or "Group identity acknowledgement type" element (U-ATTACH 
DETACH GROUP IDENTITY ACK PDU) indicates to the requester that all the requested attachments and/or 
detachments have been accepted. All or some of the accepted groups may be present in the Group identity 
uplink/downlink element of the acknowledgement. 

Examples are: 

6a) Request contains only attachments: all attachments are accepted and the Group identity uplink/downlink 
element is not present in the acknowledgement. 

6b) Request contains only attachments: all attachments are accepted, but the Group identity uplink/downlink 
element in the acknowledgement contains attachment (of some/all groups) indicating a different CoU 
than the request. 

6c) Request contains only attachments: all attachments are accepted, but the Group identity uplink/downlink 
element in the acknowledgement contains attachment (of some/all groups) indicating the attachment 
lifetime of the group (if different than the default attachment lifetime). 

6d) Request contains only detachments: all detachments are accepted and the Group identity uplink/downlink 
element is not present in the acknowledgement. 

6e) Several attachments and/or detachments in the request: all accepted. Group identity uplink/downlink 
element is not present in the acknowledgement. 

6f) Several attachments and/or detachments in the request: all accepted but the Group identity 

uplink/downlink element in the acknowledgement contains attachment(s) of one or several groups that 
were requested to be attached, indicating different CoU than the request and/or indicating the attachment 
lifetime of the group (if different than the default attachment lifetime). 

NOTE 1 : If a detachment request is accepted, the Group identity uplink/downlink element should not be included in 
the acknowledgement because it gives the requester no useful information; in fact, the difference in 
detachment reasons between the request and response may be confusing to the requester. 

7) A value of 1 (Attachment/detachment rejected) in the "Group identity accept/reject" element (D-ATTACH 
DETACH GROUP IDENTITY ACK PDU) or "Group identity acknowledgement type" element (U-ATTACH 
DETACH GROUP IDENTITY ACK PDU) indicates to the requester that at least one of the requested 
attachments and/or detachments have been rejected. All rejected groups are present in the Group identity 
uplink/downlink element of the acknowledgement. All or some of the accepted groups may be present in the 
Group identity uplink/downlink element of the acknowledgement. 

Examples are (see proposal 6 for examples of acceptance of attachment/detachment): 

7a) Request contains only attachments: one or several (maybe even all) attachments are rejected, the Group 
identity uplink/downlink element is included in the acknowledgement containing the rejected groups and 
a reject reason for each rejected group. 

7b) Request contains only detachments: one or several (maybe even all) detachments are rejected, the Group 
identity uplink/downlink element is included in the acknowledgement containing the rejected groups and 
attachment information for each rejected group. 

7c) Request contains attachments and detachments: at least one attachment and/or detachment is rejected, the 
Group identity uplink/downlink element is included in the acknowledgement containing the rejected 
group(s) and reject reason/attachment information for each rejected group. 
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8) If the responder accepts a group attachment or detachment request but does not include the group in the 
response, the responder is said to be implicitly accepting the attachment/detachment request. If the responder 
accepts or rejects a group attachment or detachment request and does include the group in the response, the 
responder is said to be explicitly accepting or rejecting the attachment/detachment request: 

8a) To explicitly accept an attachment, the responder sets the "Group identity attach/detach type identifier" 
element of the "Group identity uplink" or "Group identity downlink" element to "0" (Attachment). 

8b) To explicitly reject an attachment, the responder sets the "Group identity attach/detach type identifier" 
element of the "Group identity uplink" or "Group identity downlink" element to "1" (Detachment). 

8c) To explicitly reject a detachment, the responder sets the "Group identity attach/detach type identifier" 
element of the "Group identity uplink" or "Group identity downlink" element to "0" (Attachment). 

8d) Detachment should not be explicitly accepted - see note 1 . 

NOTE 2: Implicit rejection of a group attachment or detachment request is not permitted - see requirement 7. 

9) A MS or a SwMI may request detachment of all groups by sending a group attach/detach request without any 
groups. For all requests of this nature, with the exception of one solicited by a group report request, the "Group 
identity attach/detach mode" element shall be set to "1". ("Detach all currently active group identities and 
attach group identities...); for a group report request, the "Group identity attach/detach mode" element shall be 
set to "0" (Amendment). 

10) If a D/U- ATTACH DETACH GROUP IDENTITY PDU contains at least one detachment request and the 
"Group identity attach/detach mode" element is set to " 1 " (Detach all currently active group identities and 
attach group identities defined in the group identity downlink/uplink element), the responder shall ignore the 
detachment request(s). 

The scenarios in clauses G.2 and G.3 define contents of the group attachment/detachment related information elements 
ofPDUs. 

In the scenarios the information contained in the PDU description tables corresponds to the following key: 

• [C] denotes element upon which other elements are conditional (note that this is not a reference to annex C); 
and 

• CoU = Class of usage. 



G.2 MS-INITIATED GROUP 

ATTACHMENT/DETACHMENT 

G.2.1 SCENARIO 1 

MS requests attachment of one group; SwMI accepts attachment, ACK contains group. 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uplink: 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 
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D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = (Attachment/detachment accepted). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink: 

Group identity attach/detach type identifier = (Attach) [C]; 

Group identity attachment Hfetime = XX (Any value); 

CoU = XXX (Any value), see note; 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

NOTE: The SwMI may send a different CoU value to that requested by the MS; if the MS does not accept the 
SwMI CoU, it may send a separate U-ATTACH/DETACH GROUP IDENTITY PDU requesting 
detachment of the group. 

G.2.2 SCENARIO 2 

MS requests attachment of one group; SwMI accepts attachment, ACK does not contain group, see note. 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uplink: 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTAGH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = (Attachment/detachment accepted). 

• Group identity attach/detach mode = (Reserved). 

NOTE: Attachment lifetime of the group is the "default group attachment lifetime"; if the attachment lifetime of 
the group is different to the default, the group will be present in the ACK PDU, see scenario 1 . MS 
assumes the CoU of the group is the CoU contained in the uplink request. 
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G.2.3 SCENARIOS 

MS requests attachment of one group; SwMI rejects attachment, ACK contains group. 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity upUnk: 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = 1 (Attachment/detachment rejected). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink: 

Group identity attach/detach type identifier = 1 (Detach) [C]; 
Group identity detachment downlink = XX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

G.2.4 SCENARIO 4 

MS requests detachment of one group; SwMI accepts detachment, ACK does not contain group. 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = 0. 

• Group identity uplink: 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 
Group identity detachment uplink = XX (Any value); 
Group identity address type = XX (Any value) [C]; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = (Attachment/detachment accepted). 

• Group identity attach/detach mode = (Reserved). 
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G.2.5 SCENARIO 5 

MS requests detachment of one group; SwMI rejects detachment, ACK contains group. 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = 0. 

• Group identity upUnk: 

Group identity attach/detach type identifier = 1 (Detach) [C]; 
Group identity detachment upHnk = XX (Any value); 
Group identity address type = XX (Any value) [C]; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = 1 (Attachment/detachment rejected). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink: 

Group identity attach/detach type identifier = (Attach) [C]; 

Group identity attachment lifetime = XX (Any value); 

CoU = XXX (Any value but probably the value held by the SwMI for this MS/Group combination); 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

G.2.6 SCENARIO 6 

MS requests attachment of multiple groups; SwMI accepts all the attachments, ACK contains all the groups in the 
uplink request, see note 1 . 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uplink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 
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• Group identity uplink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = (Attachment/detachment accepted). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 
Group identity attachment lifetime = XX (Any value); 
CoU = XXX (Any value) (see note 2); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C]; 
Group identity attachment lifetime = XX (Any value); 
CoU = XXX (Any value) (see note 2); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

Group identity attachment lifetime = XX (Any value); 

CoU = XXX (Any value) (see note 2); 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

NOTE 1 : The order of groups in the downlink response does not have to match the order of groups in the uplink 

request. For example, GROUP 2 followed by GROUP 1 followed by GROUP 3 would be a valid order in 
the ACK PDU above. 
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NOTE 2: The SwMI may send a different CoU value to that requested by the MS; if the MS does not accept the 
SwMI CoU, it may send a separate D-ATTACH DETACH GROUP IDENTITY requesting detachment 
of the group. 

G.2.7 SCENARIO 7 

MS requests attachment of multiple groups; SwMI accepts all the attachments, ACK contains a subset of the groups in 
the uplink request (see note 1). 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uphnk { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = (Attachment/detachment accepted). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 
Group identity attachment lifetime = XX (Any value); 
CoU = XXX (Any value) (see note 2); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 
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• Group identity downlink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

Group identity attachment hfetime = XX (Any value); 

CoU = XXX (Any value) (see note 2); 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

NOTE 1 : Any group contained in the uplink request but not contained in the downlink response (GROUP 2 in this 
example) is implicitly attached. The attachment lifetime of the group is the "default group attachment 
lifetime", the MS assumes the CoU of the group is the CoU contained in the uplink request. 

NOTE 2: The SwMI may send a different CoU value to that requested by the MS; if the MS does not accept the 
SwMI CoU, it may send a separate D-ATTACH/DETACH GROUP IDENTITY requesting detachment 
of the group. 

G.2.8 SCENARIOS 

MS requests attachment of multiple groups; SwMI accepts all the attachments, ACK contains no groups (see note). 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uplink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uphnk { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 
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D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = (Attachment/detachment accepted). 

• Group identity attach/detach mode = (Reserved). 

NOTE: Attachment lifetime of the groups is the "default group attachment lifetime"; if the attachment lifetime of 
the group is different to the default, the group will be present in the ACK PDU, see scenario 6 (9). MS 
assumes the CoU of the group is the CoU contained in the uplink request. 

G.2.9 SCENARIO 9 

MS requests attachment of multiple groups; SwMI rejects one of the attachments, ACK contains all the groups in the 
uplink request (see note). 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uplink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uphnk { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uphnk { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 



£75/ 



1 1 71 ETSI TS 1 00 392-2 V3.3.1 (2008-1 0) 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = 1 (Attachment/detachment rejected). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 
Group identity attachment Hfetime = XX (Any value); 
CoU = XXX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 
Group identity detachment downlink = XX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

Group identity attachment lifetime = XX (Any value); 

CoU = XXX (Any value); 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

NOTE: Attachment of GROUP 1 and GROUP 3 is explicitly accepted. Attachment of GROUP 2 is expHcitly 
rejected. 

G.2.10 SCENARIO 10 

MS requests attachment of multiple groups; SwMI rejects one of the attachments, ACK contains only the rejected group 
(see note). 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uphnk { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 
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• Group identity uplink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = 1 (Attachment/detachment rejected). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 

Group identity detachment downlink = XX (Any value); 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

NOTE: Attachment of GROUP 1 and GROUP 3 is implicitly accepted. Attachment of GROUP 2 is explicitly 
rejected. 

G.2.11 SCENARIO 11 

MS requests attachment of multiple groups; SwMI rejects all the attachments, ACK contains all the groups in the uplink 
request (see note). 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = X (Either value). 

• Group identity uplink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 
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• Group identity uplink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = 1 (Attachment/detachment rejected). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 
Group identity detachment downlink = XX (Any value); 
Group identity address type see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = 1 (Detach) [C]; 
Group identity detachment downlink = XX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 
Group identity detachment downlink = XX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 
NOTE: Attachment of all groups is explicitly rejected. 
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G.2.12 SCENARIO 12 



MS requests attachment of two groups and detachment of one group; SwMI accepts one of the attachments and rejects 
the detachment and the other attachment, ACK contains all the groups in the uplink request (see note). 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = 0. 

• Group identity uphnk { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTS1/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 
Group identity detachment uplink = XX (Any value); 
Group identity address type = XX (Any value) [C]; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = 1 (Attachment/detachment rejected). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 
Group identity attachment lifetime = XX (Any value); 
CoU = XXX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 
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• Group identity downlink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C]; 
Group identity attachment hfetime = XX (Any value); 
CoU = XXX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 

Group identity detachment downlink = XX (Any value); 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

NOTE: Attachment of GROUP 1 is explicitly accepted. Detachment of GROUP 2 is explicitly rejected. 
Attachment of GROUP 3 is explicitly rejected. 

G.2.13 SCENARIO 13 

MS requests attachment of two groups and detachment of one group; SwMI accepts one of the attachments and rejects 
the detachment and the other attachment, ACK contains a subset of the groups in the uplink request (see note). 

U-ATTACH DETACH GROUP IDENTITY 

• Group identity report = (Not report requested). 

• Group identity attach/detach mode = 0. 

• Group identity uphnk { FOR GROUP 1 } : 

Group identity attach/detach type identifier = (Attach) [C]; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = 1 (Detach) [C]; 
Group identity detachment uplink = XX (Any value); 
Group identity address type = XX (Any value) [C]; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 

• Group identity uplink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = (Attach) [C] ; 

CoU = XXX (Any value); 

Group identity address type = XX (Any value) [C]; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI. 
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D-ATTACH DETACH GROUP IDENTITY ACK 

• Group identity accept/reject = 1 (Attachment/detachment rejected). 

• Group identity attach/detach mode = (Reserved). 

• Group identity downlink { FOR GROUP 2 } : 

Group identity attach/detach type identifier = (Attach) [C]; 
Group identity attachment Hfetime = XX (Any value); 
CoU = XXX (Any value); 
Group identity address type = see table G.2; 
GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

• Group identity downlink { FOR GROUP 3 } : 

Group identity attach/detach type identifier = 1 (Detach) [C] ; 

Group identity detachment downlink = XX (Any value); 

Group identity address type = see table G.2; 

GSSI/GTSI/(V)GSSI/GTSI-(V)GSSI = see table G.2. 

NOTE: Attachment of GROUP 1 is implicitly accepted. Detachment of GROUP 2 is explicitly rejected. 
Attachment of GROUP 3 is explicitly rejected. 

as SwMI-INITIATED GROUP 

ATTACHMENT/DETACHMENT 

The principles of SwMI-initiated group attachment/detachment are the same as those for MS -initiated group 
attachment/detachment with the following exceptions: 

1 ) The PDU exchange is D-ATTACH DETACH GROUP IDENTITY / U- ATT ACH DETACH GROUP 
IDENTITY ACK. 

2) The "Group identity accept/reject" element in the SwMI ACK becomes a "Group identity acknowledgement 
type" element in the MS ACK (the bit orientation and the meaning of the bit values is identical between the 
two elements). 

3) The SwMI may request that the MS does not send an ACK (via "Group identity acknowledgement request" 
element in the D-ATTACH DETACH GROUP IDENTITY PDU). If the MS wishes to reject a SwMI-initiated 
attachment or detachment but is prevented from sending an ACK by the SwMI, the MS may initiate a separate 
U-ATTACH DETACH GROUP IDENTITY / D-ATTACH DETACH GROUP IDENTITY ACK PDUs 
transaction with the SwMI. 

4) The U-ATTACH DETACH GROUP IDENTITY ACK PDU does not contain a "Group identity attach/detach 
mode" element (refer to proposal 3). 

5) SwMI requests attachment/detachment with the "Group identity downlink" element; MS requests attachment / 
detachment with the "Group identity uplink" element. SwMI ACKs attachment / detachment with the "Group 
identity downlink" element; MS ACKs attachment / detachment with the "Group identity uplink" element. 

6) The MS may send a different CoU value in the ACK to that requested by the SwMI. If the SwMI does not 
accept the MS CoU, it may send a separate D-ATTACH / DETACH GROUP IDENTITY PDU enforcing 
detachment of the group, refer to note 1 of scenario 1 . 

7) The MS cannot reject a SwMI-requested group detachment (refer to proposal 4). 
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Annex H (normative): 

TETRA proprietary information element owner 

This annex defines TETRA proprietary information element owner. 



H.1 Proprietary information element 

TETRA protocols for CMCE and MM contain optional proprietary information elements. In order to identify and 
differentiate various implementations of the proprietary elements a proprietary element owner is defined as the first 
information element of the proprietary element, refer to clauses 14.8.35 and 16.10.41. 

The proprietary element owner information element shall contain elements as defined in table H. 1 . 

Table H.I : Proprietary element owner contents 



Information element 


Length 


Type 


C/O/M 


Value 


Remark 


Proprietary element owner 


8 


1 


M 


OOOOOOOO2 


Extension indicator, (see note 1 ) 


00000001 2 


Owner 1 


etc. 


etc. 


IIIIIIII2 


Owner 255 


Proprietary element owner 
extension 


Reserved 


1 


C 


All values 
reserved 


See note 2 


NOTE 1 : This value shall indicate that the proprietary element owner is indicated by the proprietary element 

owner extension information element. This value is not used in the edition 2 of the present document. 

NOTE 2: This information element shall be present only when the proprietary element owner information 

element has the value OOOOOOOO2. This information element is not used in the edition 2 of the present 
document. 



The proprietary element owner values are managed by a central body. 

Each manufacture should have only a single value of the proprietary element owner information element. The 
manufacture should design his proprietary information element contents so that he can use the same proprietary element 
owner value for various purposes. It is recommended that the proprietary information part is coded so that it contains in 
the beginning a protocol identifier, a PDU type or an information element type managed by that manufacturer so that 
the usage of the single proprietary element owner value can be continued as long as possible. 

It is allowed that multiple manufacturers use the same proprietary element owner value under responsibility of the 
registered owner. 

H.2 Application for the proprietary element owner value 

This application form is provided under assumption that ETSI will be the central body for the management of the 
proprietary element owner values of the edition 2 of the present document. The application and allocation may be 
implemented by other means such as a World Wide Web server application. 
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1(2) 
PROVISION OF AND RESTRICTED USAGE UNDERTAKING 

relating to 

a proprietary element owner information element value, to be used in mobile and line stations and in TETRA SwMls 
for Terrestrial Trunked Radio (TETRA) systems. 

Between 

(COMPANY NAME) 

(COMPANY ADDRESS) 

hereinafter called: the BENEFICIARY; 
and 

(COMPANY NAME) European Telecommunications Standards Institute 

(COMPANY ADDRESS) 06921 Sophia Antipohs CEDEX, France 

hereinafter called: the PROVIDER. 

• Whereas 

The BENEFICIARY has alleged that he fulfils the following criteria: 

• He is a manufacturer of TETRA equipment. 

The PROVIDER undertakes to give to the BENEFICIARY: 

• One globally unique proprietary element owner information element value, registered by the PROVIDER. 

The provided proprietary element owner information element value is filled in below by the PROVIDER when he has 
received and approved two signed originals of this agreement. 



Proprietary element owner: 



Decimal number Binary number 

The code above is given as a decimal (1 to 255) number, and as a 8 bit binary number (OOOOOOOI2 to 1111111 12). The 
most significant digit and bit are positioned to the left. 
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2(2) 



The BENEFICIARY undertakes: 



1 . To apply and use the proprietary element owner value in accordance with rules in annex H of the present 
document. 

2. To return the proprietary element owner value to the PROVIDER, within 5 years, if these has not been used. 

EN 300 392-2: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air Interface (AI)", annex H. 

In case the BENEFICIARY violates any of the obligations incurred on him by the present undertaking, he shall be 
liable of indemnifying ETSI for all losses suffered directly or through claims from legitimate TETRA users. 

All disputes which derive from the present undertaking or its interpretation shall be settled by the Court of Arbitration 
of the International Chamber of Commerce situated in Paris, in accordance with the procedures of this Court of 
Arbitration and with the application of French Law regarding questions of interpretation. 

Made in two originals, one of which is for the PROVIDER, the other for the BENEFICIARY; both originals signed by 
a legal representative of his company/organization. 

For the PROVIDER For the BENEFICIARY 

(signed) 

(Name, Title (typed)) 



(signed) 

K H Rosenbrock, Director General (Name, Title (typed)) . 

(Date) (Date) 
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Annex I (normative): 

TETRA SDS-TL Location system coding scheme 

information element owner 

This annex defines TETRA SDS-TL Location system coding scheme information element owner. 

1.1 Location system coding scheme information element 

TETRA SDS-TL in clause 29.5.7 defines Location system coding scheme identifiers for various location information 
transport protocols. Some of the potential protocols are defined in the SDS-TL standard in clause 29 and some protocol 
will be defined independently of the clause 29. In order to identify the manufacturer specific protocols the Location 
system coding scheme identifiers are allocated by a central body. The manufacturer means in this context the owner of 
the Location system coding scheme such as a TETRA equipment manufacturer, a TETRA application designer or 
TETRA operator. 

NOTE 1 : Location system coding scheme identifiers is a generic name for location information transport protocols 
and is not limited to GPS only although the earlier name of the information element (GPS coding scheme) 
may imply that limitation. 

NOTE 2: In addition to the "Location system" TETRA SDS-TL Protocol Identifier (PID) TETRA standard contains 
another PID for a standardized location information transport protocol, refer to TS 100 392-18-1 [19]. 

There is a range on the Location system coding scheme identifiers available for the manufacturer specific protocols as 
defined in the clause 29.5.7. 

The Location system coding scheme identifier values are managed by a central body. 

Each manufacture may have multiple values of the Location system coding scheme identifier information element. The 
manufacture may design his proprietary information element contents so that he can use the same Location system 
coding scheme identifier value for all purposes of location information transport protocol. The manufacturer specific 
Location system coding scheme information part may be coded so that it contains in the beginning a PDU type or 
an information element type managed by that manufacturer so that the usage of the single protocol identifier value can 
be used for all purposes for that protocol. The same Location system coding scheme identifier value may be used for 
various protocols if suitable on the manufacturers point of view. 

It is allowed that multiple manufacturers, operators or application designers use the same Location system coding 
scheme identifier value under responsibility of the registered owner. 



L2 Application for the Location system coding scheme 
identifier value 

This application form is provided under assumption that ETSI will be the central body for the management of the 
SDS-TL Location system coding scheme identifier owner values of the present document. The application and 
allocation may be implemented by other means such as a World Wide Web server application. 
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1(2) 
PROVISION OF AND RESTRICTED USAGE UNDERTAKING 

relating to 

a SDS-TL Location system coding scheme information element value, to be used in mobile and line stations, in 
application using TETRA equipment and in TETRA SwMIs for Terrestrial Trunked Radio (TETRA) systems. 

Between 

(COMPANY NAME) 

(COMPANY ADDRESS) 

hereinafter called: the BENEFICIARY; 
and 

(COMPANY NAME) European Telecommunications Standards Institute 

(COMPANY ADDRESS) 06921 Sophia Antipohs CEDEX, France 

hereinafter called: the PROVIDER. 

• Whereas 

The BENEFICIARY has alleged that he fulfils the following criteria: 

• He is a manufacturer of TETRA equipment. 

The PROVIDER undertakes to give to the BENEFICIARY: 

• One globally unique SDS-TL Location system coding scheme information element value, registered by the 
PROVIDER. 

The provided SDS-TL Location system coding scheme information element value is filled in below by the 
PROVIDER when he has received and approved two signed originals of this agreement. 



SDS-TL Location system coding scheme: 



Decimal number Binary number 



The code above is given as a decimal (128 to 254) number, and as an 8 bit binary number (IOOOOOOO2 to 111111 IO2). 
The most significant digit and bit are positioned to the left. 
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2(2) 



The BENEFICIARY undertakes: 



1 . To apply and use the SDS-TL Location system coding scheme value in accordance with rules in annex I of 
the present document. 

2. To return the SDS-TL Location system coding scheme value to the PROVIDER, within 5 years, if these has 
not been used. 

EN 300 392-2: "Terrestrial Trunked Radio (TETRA); Voice plus Data (Vh-D); Part 2: Air Interface (AI)", annex I. 

In case the BENEFICIARY violates any of the obligations incurred on him by the present undertaking, he shall be 
liable of indemnifying ETSI for all losses suffered directly or through claims from legitimate TETRA users. 

All disputes which derive from the present undertaking or its interpretation shall be settled by the Court of Arbitration 
of the International Chamber of Commerce situated in Paris, in accordance with the procedures of this Court of 
Arbitration and with the application of French Law regarding questions of interpretation. 

Made in two originals, one of which is for the PROVIDER, the other for the BENEFICIARY; both originals signed by 
a legal representative of his company/organization. 

For the PROVIDER For the BENEFICIARY 



(signed) . 



(Name, Title (typed)) . 



(signed) . 



K H Rosenbrock, Director General (Name, Title (typed)) . 



(Date) (Date) 
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Annex J (normative): 

TETRA SDS-TL protocol identifier information element 

owner 

This annex defines TETRA SDS-TL protocol identifier information element owner. 

J.1 Protocol identifier information element 

TETRA SDS-TL in clause 29.4.3.9 defines protocol identifiers for various SDS-TL protocols. Some of the potential 
protocols are defined in the SDS-TL standard in clause 29 and some protocol will be defined independently of the 
clause 29. In order to identify the manufacturer specific protocols the protocol identifiers are allocated by a central 
body. The manufacturer means in this context either a TETRA equipment manufacturer, or a TETRA application 
designer or TETRA application protocol owner. 

There are two ranges on protocol identifiers available for the manufacturer specific protocols as defined in the 
clause 29.4.3.9 and copied in a short form into table J.l. 

Table J.l : SDS-TL protocol identifier information element contents 



Information element 


Length 


Type 


C/O/M 


Value 


Remark 


Protocol identifier 


8 


1 


M 


OIOOOOOO2 

to 
OIIIIIIO2 


The SDS-TL protocol PDUs are 
not used (see note 1). 


IIOOOOOO2 

to 
IIIIIIIO2 


The SDS-TL protocol PDUs are 
used (see note 2). 


All other 
values 


These values are outside the 
scope of this annex. 


NOTE 1 : For ttiese values each SDS type 4 user data information element contains as the standardized part the 
protocol identifier as the first 8 bits. The rest of the user data information is outside the scope of the 
present document. In the application form this is indicated as "no SDS-TL service". 

NOTE 2: For these values each SDS type 4 user data information element contains as the standardized part 
one of the SDS-TL PDUs as defined in clause 29.4.2. The SDS-TL PDUs contain as the first 
information element the protocol identifier. In the application form this is indicated as "SDS-TL 
service". 



The protocol identifier values are managed by a central body. 

Each manufacture may have multiple values of the protocol identifier information element. The manufacture should 
design his proprietary information element contents so that he can use the same protocol identifier value for all purposes 
of a protocol. It is recommended that the manufacturer specific protocol information part is coded so that it contains in 
the beginning a PDU type or an information element type managed by that manufacturer so that the usage of the single 
protocol identifier value can be used for all purposes for that protocol. The same protocol identifier value may be used 
for various protocols if suitable on the manufacturers' point of view. 

It is allowed that multiple manufacturers or application designers use the same protocol identifier value under 
responsibility of the registered owner. 



J. 2 Application for the protocol identifier value 

This application form is provided under assumption that ETSI will be the central body for the management of the 
SDS-TL protocol identifier owner values of the present document. The application and allocation may be implemented 
by other means such as a World Wide Web server application. The applicant shall indicate the range on which the SDS- 
TL Protocol Identifier is applied. Only a single range can be present in each application form. 
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1(2) 



PROVISION OF AND RESTRICTED USAGE UNDERTAKING 

relating to 

a SDS-TL protocol identifier information element value, to be used in mobile and line stations, in application using 
TETRA equipment and in TETRA SwMls for Terrestrial Trunked Radio (TETRA) systems. 

Between 

(COMPANY NAME) 

(COMPANY ADDRESS) 



hereinafter called: the BENEFICIARY; 
and 

(COMPANY NAME) European Telecommunications Standards Institute 

(COMPANY ADDRESS) 06921 Sophia Antipohs CEDEX, France 

hereinafter called: the PROVIDER. 

• Whereas 

The BENEFICIARY has alleged that he fulfils the following criteria: 

• He is a manufacturer of TETRA equipment, or a TETRA application designer or TETRA application protocol 
owner. 

The PROVIDER undertakes to give to the BENEFICIARY: 

• One globally unique SDS-TL protocol identifier information element value, registered by the PROVIDER. 
The BENEFICIARY applies for an SDS-TL protocol identifier 



for no SDS-TL service: 
for SDS-TL service: 



decimal number value in range 64 to 126 
decimal number value in range 192 to 254 



The provided SDS-TL protocol identifier information element value is filled in below by the PROVIDER when he has 
received and approved two signed originals of this agreement. 



SDS-TL protocol identifier: 

Decimal number 



Binary number 



The code above is given as a decimal (64 to 126 or 192 to 254) number, and as a 8 bit binary number (OIOOOOOO2 to 
011111 102.or 1 IOOOOOO2 to 1 1 1 1 1 1 IO2). The most significant digit and bit are positioned to the left. 
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2(2) 



The BENEFICIARY undertakes: 



1 . To apply and use the SDS-TL protocol identifier value in accordance with rules in annex J of the present 
document. 

2. To return the SDS-TL protocol identifier value to the PROVIDER, within 5 years, if these has not been used. 

EN 300 392-2: "Terrestrial Trunked Radio (TETRA); Voice plus Data (Vh-D); Part 2: Air Interface (AI)", annex J. 

In case the BENEFICIARY violates any of the obligations incurred on him by the present undertaking, he shall be 
liable of indemnifying ETSI for all losses suffered directly or through claims from legitimate TETRA users. 

All disputes which derive from the present undertaking or its interpretation shall be settled by the Court of Arbitration 
of the International Chamber of Commerce situated in Paris, in accordance with the procedures of this Court of 
Arbitration and with the application of French Law regarding questions of interpretation. 

Made in two originals, one of which is for the PROVIDER, the other for the BENEFICIARY; both originals signed by 
a legal representative of his company/organization. 

For the PROVIDER For the BENEFICIARY 



(signed) . 



(Name, Title (typed)) . 



(signed) . 



K H Rosenbrock, Director General (Name, Title (typed)) . 



(Date) (Date) 
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Annex K (informative): 

TETRA IVIobile Country Code information element values 

K.1 Management of TETRA Mobile Country Codes 

ITU-T manages TETRA Mobile Country Codes in contrary what is defined in edition 1 of EN 300 392-1 [6] 
clause 7.2.5, refer to http://www.itu.int/ . 

K.2 TETRA Mobile Country Code information element 
values 

Refer to ITU-T recommendation E.218 [42], http://www.itu.int/ . 
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Annex M (informative): 
Table and figure numbering 



Table M.l compares table numbers of EN 300 392-2 versions up to V2.4.2 and table numbers of TS 100 392-2 and 
EN 300 392-2 V2.5.1, V2.5.2 and V2.6.1. In the later versions than TS 100 392-2 and EN 300 392-2 V2.5.1, V2.5.2 and 
V2.6.1 the table numbers may be different than those in the table M.l. Table M.l identifies by bold font table numbers 
that are referenced to from other clauses than those in each editorial sub-part of EN 300 392-2 or from other TETRA 
specifications or standards at the time of drafting of the present document. That marking may not be complete. 

Table M.l : Table numbering 



Versions 
V2.4.2and V2.4.1 
Figure Clause 


Versions 

V2.5.1,V2.5.2and 

V2.6.1 

Clause.figure 


Name 


1 


5.4 


5.1 


Phase transitions 


2 


6.4.1.1 


6.1 


Nominal power of BS transmitters 


3 


6.4.1.2 


6.2 


Nominal power of IVIS transmitters 


4 


6.4.1.2 


6.3 


Nominal IVIS power control levels 


5a 


6.4.2.2.1 


6.4 


Maximum adjacent power levels for frequencies below 
700 MHz 


5b 


6.4.2.2.1 


6.5 


Maximum adjacent power levels for frequencies above 
700 MHz 


6a 


6.4.2.3 


6.6 


Wideband noise limits for frequencies below 700 MHz 


6b 


6.4.2.3 


6.7 


Wideband noise limits for frequencies above 700 MHz 


7 


6.4.5 


6.8 


Transmit level versus time mask symbol durations (re 
figure 6.3) 


8 


6.5.1.2 


6.9 


Blocking levels of the receiver 


9 


6.6.2.1 


6.10 


Nominal error rates 


10 


6.6.2.2.1 


6.11 


Maximum permissible BS receiver MER or BER at dynamic 
reference sensitivity level 


11 


6.6.2.2.2 


6.12 


Maximum permissible MS receiver MER or BER at dynamic 
reference sensitivity level 


12 


6.6.2.3.1 


6.13 


Maximum permissible BS receiver MER or BER at reference 
interference level 


13 


6.6.2.3.2 


6.14 


Maximum permissible MS receiver MER or BER at reference 
interference level 


14 


6.6.2.4.1 


6.15 


Maximum permissible BS receiver MER or BER at static 
reference sensitivity level 


15 


6.6.2.4.2 


6.16 


Maximum permissible MS receiver MER or BER at static 
reference sensitivity level 


16 


6.6.2.5 


6.17 


MS receiver performance for synchronization burst acquisition 


17 


6.6.3.3 


6.18 


Propagation models 


18 


9.4.4.1 


9.1 


Burst types 


19 


9.4.4.2.1 


9.2 


Control uplink Burst (CB) 


20 


9.4.4.2.4 


9.3 


Normal Uplink Burst (NUB) 


21 


9.4.4.2.5 


9.4 


Normal continuous downlink burst 


22 


9.4.4.2.6 


9.5 


Synchronization continuous downlink burst 


23 


9.4.4.2.7 


9.6 


Normal discontinuous downlink burst 


24 


9.4.4.2.8 


9.7 


Synchronization discontinuous downlink burst 


25 


9.4.4.3.2 


9.8 


Training sequence mapping to logical channels 


26 


9.4.4.3.6 


9.9 


Phase adjustment bits 


27 


9.4.5.1 


9.10 


Start burst 


28 


9.4.5.1 


9.11 


Stop burst 


29 


9.4.5.2 


9.12 


Bits following the burst 


30 


9.4.5.2 


9.13 


Bits preceding the burst 


31 


9.4.5.3 


9.14 


Bits following the burst 


32 


9.4.5.3 


9.15 


Bits preceding the burst 


33 


9.5.1 


9.16 


Mapping of logical channel into physical channels 


34 


9.5.1 


9.17 


TDMA frame mapping on TP channel 


35 


9.5.1 


9.18 


TDMA frame mapping on CP channel 


36 


9.5.1 


9.19 


TDMA frame mapping on unallocated physical channel 
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Versions 
V2.4.2and V2.4.1 
Figure Clause 


Versions 

V2.5.1,V2.5.2and 

V2.6.1 

Clause.figure 


Name 


37 


9.5.2 


9.20 


Mapping of the BCCH onto the control frame 


38 


9.6 


9.21 


Monitoring patterns for transmitting MSs 


39 


9.8.2 


9.22 


Reserved frames in BS timing 


40 


9.8.2 


- 


Void 


41 


11.3.3.1 


11.1 


Parameters for the primitive TNCC-ALERT 


42 


11.3.3.2 


11.2 


Parameters for the primitive TNCC-COMPLETE 


43 


11.3.3.3 


11.3 


Parameters for the primitive TNCC-DTMF 


44 


11.3.3.4 


11.4 


Parameters for the primitive TNCC-MODIFY 


45 


11.3.3.5 


11.5 


Parameters for the primitive TNCC-NOTIFY 


46 


11.3.3.6 


11.6 


Parameters for the primitive TNCC-PROCEED 


47 


11.3.3.7 


11.7 


Parameters for the primitive TNCC-RELEASE 


48 


11.3.3.8 


11.8 


Parameters for the primitive TNCC-SETUP 


49 


11.3.3.9 


11.9 


Parameters for the primitive TNCC-TX 


50 


11.3.4 


- 


Void 


51 


12.3.1 


12.1 


Parameters for the supplementary service primitives 


52 


12.3.2 


- 


Void 


53 


13.3.2.1 


13.1 


Parameters for the TNSDS-STATUS primitive 


54 


13.3.2.2 


13.2 


Parameters for the TNSDS-REPORT primitive 


55 


13.3.2.3 


13.3 


Parameters for the TNSDS-UNITDATA primitive 


56 


14.5.3.1 


14.1 


Traffic channel assignment 


57 


14.5.6.2 


14.2 


Low/high/emergency PDU priority default values 


58 


14.6 


14.3 


Timers 


59 


14.7 


- 


Void 


60 


14.7.1.1 


14.4 


D-ALERT PDU contents 


61 


14.7.1.2 


14.5 


D-CALL PROCEEDING PDU contents 


62 


14.7.1.3 


14.6 


D-CALL RESTORE PDU contents 


63 


14.7.1.4 


14.7 


D-CONNECT PDU contents 


64 


14.7.1.5 


14.8 


D-CONNECT ACKNOWLEDGE PDU contents 


65 


14.7.1.6 


14.9 


D-DISCONNECT PDU contents 


66 


14.7.1.7 


14.10 


D-FACILITY PDU contents 


67 


14.7.1.8 


14.11 


D-INFO PDU contents 


68 


14.7.1.9 


14.12 


D-RELEASE PDU contents 


69 


14.7.1.10 


14.13 


D-SDS-DATA PDU contents 


70 


14.7.1.11 


14.14 


D-STATUS PDU contents 


71 


14.7.1.12 


14.15 


D-SETUP PDU contents 


72 


14.7.1.13 


14.16 


D-TX CEASED PDU contents 


73 


14.7.1.14 


14.17 


D-TX CONTINUE PDU contents 


74 


14.7.1.15 


14.18 


D-TX GRANTED PDU contents 


75 


14.7.1.16 


14.19 


D-TX INTERRUPT PDU contents 


76 


14.7.1.17 


14.20 


D-TX WAIT PDU contents 


77 


14.7.2.1 


14.21 


U-ALERT PDU contents 


78 


14.7.2.2 


14.22 


U-CALL RESTORE PDU contents 


79 


14.7.2.3 


14.23 


U-CONNECT PDU contents 


80 


14.7.2.4 


14.24 


U-DISCONNECT PDU contents 


81 


14.7.2.5 


14.25 


U-FACILITY PDU contents 


82 


14.7.2.6 


14.26 


U-INFO PDU contents 


83 


14.7.2.7 


14.27 


U-STATUS PDU contents 


84 


14.7.2.8 


14.28 


U-SDS-DATA PDU contents 


85 


14.7.2.9 


14.29 


U-RELEASE PDU contents 


86 


14.7.2.10 


14.30 


U-SETUP PDU contents 


87 


14.7.2.11 


14.31 


U-TX CEASED PDU contents 


88 


14.7.2.12 


14.32 


U-TX DEMAND PDU contents 


88a 


14.7.3.2 


14.33 


CMCE FUNCTION NOT SUPPORTED PDU contents 


89 


14.8.1 


14.34 


Area selection information element contents 


90 


14.8.2 


14.35 


Basic service information element contents 


91 


14.8.3 


14.36 


Call identifier information element contents 


91a 


14.8.3a 


14.37 


Call identifier present information element contents 


92 


14.8.4 


14.38 


Call ownership information element contents 


93 


14.8.5 


14.39 


Called party type identifier information element contents 


94 


14.8.6 


14.40 


Called party SNA information element contents 


95 


14.8.7 


14.41 


Called party extension information element contents 
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Versions 
V2.4.2and V2.4.1 
Figure Clause 


Versions 

V2.5.1,V2.5.2and 

V2.6.1 

Clause.figure 


Name 


96 


14.8.8 


14.42 


Called party SSI information element contents 


97 


14.8.9 


14.43 


Calling party type identifier information element contents 


98 


14.8 


10 


14.44 


Calling party extension information element contents 


99 


14.8 


11 


14.45 


Calling party SSI information element contents 


100 


14.8 


12 


14.46 


Call priority information element contents 


101 


14.8 


13 


14.47 


Call status information element contents 


102 


14.8 


14 


14.48 


Call queued information element contents 


103 


14.8 


15 


14.49 


Continue information element contents 


104 


14.8 


16 


14.50 


Call time-out information element contents 


105 


14.8 


17 


14.51 


Call time-out, set-up phase information element contents 


105a 


14.8.17a 


14.52 


Circuit mode type information element contents 


105b 


14.8.17b 


14.53 


CLIR control information element contents 


105c 


14.8.17c 


14.54 


Communication type information element contents 


106 


14.8.18 


14.55 


Disconnect cause information element contents 


107 


14.8.19 


14.56 


DTMF information element contents 


107a 


14.8.19a 


14.57 


DTMF digit information element contents 


107b 


14.8.19b 


14.58 


DTMF type information element contents 


108 


14.8.20 


14.59 


Encoding of the digits in the external subscriber number 
information element 


109 


14.8.21 


14.60 


Encryption control information element contents 


109a 


14.8.21a 


14.61 


Encryption flag information element contents 


110 


14.8.23 


14.62 


Hook method selection information element contents 


111 


14.8.24 


14.63 


Length indicator information element contents 


112 


14.8.26 


14.64 


Modify information element contents 


113 


14.8.27 


14.65 


Notification indicator information element contents 


114 


14.8.28 


14.66 


PDU type information element contents 


115 


14.8.29 


14.67 


Poll request information element contents 


116 


14.8.30 


14.68 


Poll response information element contents 


117 


14.8.31 


14.69 


Poll response addresses information element contents 


118 


14.8.32 


14.70 


Poll response number information element contents 


119 


14.8.33 


14.71 


Poll response percentage information element contents 


120 


14.8.34 


14.72 


Pre-coded status information element contents 


120a 


14.8.35 


14.73 


Proprietary information element contents 


121 


14.8.36 


14.74 


Request to transmit/send data information element contents 


122 


14.8.37 


14.75 


Reset call time-out timer information element contents 


123 


14.8.38 


14.76 


Short data type identifier information element contents 


124 


14.8.39 


14.77 


Simplex/duplex selection information element contents 


124a 


14.8.39a 


14.78 


Slots per frame information element contents 


125 


14.8.40 


14.79 


Speech service information element contents 


126 


14.8.42 


14.80 


Transmission grant information element contents 


127 


14.8.43 


14.81 


Transmission request permission information element contents 


128 


14.8.44 


14.82 


Transmitting party type identifier information element contents 


129 


14.8.45 


14.83 


Transmitting party extension information element contents 


130 


14.8.46 


14.84 


Transmitting party SSI information element contents 


131 


14.8.47 


14.85 


Tx demand priority information element contents 


132 


14.8.48 


14.86 


Type 3 element identifier information element contents 


133 


14.8.49 


14.87 


User Defined Data-1 information element contents 


134 


14.8.50 


14.88 


User Defined Data-2 information element contents 


135 


14.8.51 


14.89 


User Defined Data-3 information element contents 


136 


14.8.52 


14.90 


User Defined Data-4 information element contents 


137 


15.3.3.1 


15.1 


Parameters for the primitive TNMM-ATTACH DETACH 
GROUP IDENTITY 


138 


15.3.3.2 


15.2 


Parameters for the primitive TNMM-DEREGISTRATION 


139 


15.3.3.3 


- 


Void 


140 


15.3.3.4 


- 


Void 


141 


15.3.3.5 


15.3 


Parameters for the primitive TNMM-ENERGY SAVING 


142 


15.3.3.6 


15.4 


Parameters for the primitive TNMM-ENERGY SAVING 


143 


15.3.3.7 


15.5 


Parameters for the primitive TNMM-REGISTRATION 


144 


15.3.3.8 


15.6 


Parameters for the primitive TNMM-SERVICE 


144a 


15.3.3.9 


15.7 


Parameters for the primitive TNMM-STATUS 


145 


15.3.4 


15.8 


Group identities parameter 


146 


15.3.4 


15.9 


Group identity request parameter 
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Name 


147 


16.9.1 


- 


Void 


148 


16.9.2.1 


16.1 


D-ATTACH/DETACH GROUP IDENTITY PDU contents 


149 


16.9.2.2 


16.2 


D-ATTACH/DETAGH GROUP IDENTITY 
ACKNOWLEDGEMENT PDU contents 


150 


16.9.2.3 


- 


Void 


151 


16.9.2.4 


- 


Void 


152 


16.9.2.5.1 


16.3 


D-IVIM STATUS PDU generic contents 


152a 


16.9.2.5.2 


16.4 


D-CHANGE OF ENERGY SAVING MODE REQUEST PDU 
contents 


152B 


16.9.2.5.3 


16.5 


D-CHANGE OF ENERGY SAVING MODE RESPONSE PDU 
contents 


152C 


16.9.2.5.4 


16.6 


D-DUAL WATCH MODE RESPONSE PDU contents 


152D 


16.9.2.5.5 


16.7 


D-TERMINATING DUAL WATCH MODE RESPONSE PDU 
contents 


152E 


16.9.2.5.6 


16.8 


D-CHANGE OF DUAL WATCH MODE REQUEST PDU 
contents 


152F 


16.9.2.5.8 


16.9 


D-MS FREQUENCY BANDS REQUEST PDU contents 


152G 


16.9.2.5.9 


16.10 


D-DISTANCE REPORTING REQUEST PDU contents 


153 


16.9.2.6 


- 


Void 


154 


16.9.2.7 


16.11 


D-LOCATION UPDATE ACCEPT contents 


155 


16.9.2.8 


16.12 


D-LQCATION UPDATE COMMAND contents 


156 


16.9.2.9 


16.13 


D-LOCATIQN UPDATE REJECT contents 


157 


16.9.2.10 


16.14 


D-LOCATION UPDATE PROCEEDING contents 


158 


16.9.3.1 


16.15 


U-ATTACH/DETACH GROUP IDENTITY contents 


159 


16.9.3.2 


16.16 


U-ATTACH/DETACH GROUP IDENTITY 
ACKNOWLEDGEMENT contents 


160 


16.9.3.3 


16.17 


U-ITSI DETACH contents 


161 


16.9.3.4 


16.18 


U-LOCATIQN UPDATE DEMAND contents 


162 


16.9.3.5.1 


16.19 


U-MM STATUS PDU generic contents 


162a 


16.9.3.5.2 


16.20 


U-CHANGE OF ENERGY SAVING MODE REQUEST PDU 
contents 


162B 


16.9.3.5.3 


16.21 


U-CHANGE OF ENERGY SAVING MODE RESPONSE PDU 
contents 


162C 


16.9.3.5.4 


16.22 


U-DUAL WATCH MODE REQUEST PDU contents 


162D 


16.9.3.5.5 


16.23 


U-TERMINATING DUAL WATCH MODE REQUEST PDU 
contents 


162E 


16.9.3.5.6 


16.24 


U-CHANGE OF DUAL WATCH MODE RESPONSE PDU 
contents 


162F 


16.9.3.5.7 


16.25 


U-START OF DIRECT MODE OPERATION PDU contents 


162Fb 


16.9.3.5.9 


16.26 


U-MS FREQUENCY BANDS PDU contents 


162G 


16.9.4.1 


16.27 


MM FUNCTION NOT SUPPORTED PDU contents 


163 


16.10.1 


16.28 


Address extension information element contents 


164 


16.10.2 


16.29 


Cipher control information element contents 


165 


16.10.3 


- 


Void 


166 


16.10.4 


- 


Void 


167 


16.10.5 


16.30 


Class of MS information element contents 


168 


16.10.6 


16.31 


Class of Usage information element contents 


169 


16.10.7 


- 


Void 


169a 


16.10.7a 


16.32 


Default group attachment lifetime information element contents 


169B 


16.10.7b 


16.33 


Distance reporting timer information element contents 


169C 


16.10.7c 


16.34 


Distance reporting validity information element contents 


170 


16.10.8 


16.35 


Distribution on 18th frame 


170A 


16.10.8a 


16.36 


DM0 carrier 


170B 


16.10.8b 


16.37 


Dual watch mode information element contents 


171 


16.10.9 


16.38 


Energy saving mode information element contents 


172 


16.10.10 


16.39 


Energy saving information element contents 


173 


16.10.11 


16.40 


Frame number information element contents 


173a 


16.10.11a 


16.41 


Frequency band definition information element contents 


174 


16.10.12 


16.42 


Group identity accept/reject information element contents 


175 


16.10.13 


16.43 


Group identity acl<nowledgement request information element 
contents 


176 


16.10.14 


16.44 


Group identity acknowledgement type information element 
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Versions 

V2.5.1,V2.5.2and 

V2.6.1 
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Name 








contents 


177 


16.10.15 


16.45 


Group identity address type information element contents 


178 


16.10.16 


16.46 


Group identity attachment lifetime information element 
contents 


179 


16.10.17 


16.47 


Group identity attach/detach mode information element 
contents 


180 


16.10.18 


16.48 


Group identity attach/detach type identifier information element 
contents 


181 


16.10.19 


16.49 


Group identity attachment information element contents 


182 


16.10.20 


16.50 


Group identity detachment downlink information element 
contents 


183 


16.10.21 


16.51 


Group identity detachment uplink information element contents 


184 


16.10.22 


16.52 


Group identity downlink information element contents 


185 


16.10.23 


16.53 


Group identity location accept information element contents 


186 


16.10.24 


16.54 


Group identity location demand information element contents 


187 


16.10.25 


- 


Void 


188 


16.10.26 


16.55 


Group identity report information element contents 


189 


16.10.27 


16.56 


Group identity uplink information element contents 


189a 


16.10.27a 


16.57 


Group report response information element contents 


190 


16.10.28 


16.58 


GSSI information element contents 


191 


16.10.29 


- 


Void 


192 


16.10.30 


16.59 


LA information element contents 


193 


16.10.31 


16.60 


Location Area Country Code information element contents 


194 


16.10.32 


16.61 


LANC information element contents 


195 


16.10.33 


16.62 


LA timer information element contents 


196 


16.10.34 


16.63 


LA information element contents 


196A 


16.10.34a 


16.64 


Length of the copied PDU information element contents 


197 


16.10.35 


16.65 


Location update type information element contents 


197a 


16.10.35a 


16.66 


Location update accept type information element contents 


198 


16.10.36 


16.67 


MCC information element contents 


199 


16.10.37 


16.68 


MNC information element contents 


199a 


16.10.37a 


16.69 


Mode change information element contents 


199b 


16.10.37b 


16.70 


MS operating with type 2 repeater information element 
contents 


200 


16.10.38 


16.71 


Multiframe number information element contents 


200A 


16.10.38b 


16.72 


Number of the frequency band definitions information element 
contents 


201 


16.10.39 


16.73 


PDU type information element contents 


202 


16.10.40 


16.74 


New registered area information element contents 


202a 


16.10.41a 


16.75 


Reason for dual watch change by SwMI information element 
contents 


203 


16.10.42 


16.76 


Reject cause information element contents 


204 


16.10.43 


16.77 


Request to Append LA information element contents 


204a 


16.10.43a 


16.78 


Re-send interval information element contents 


204B 


16.10.43b 


16.79 


Result of dual watch request information element contents 


205 


16.10.44 


16.80 


SSI information element content 


206 


16.10.45 


16.81 


SCCH information element contents 


207 


16.10.46 


16.82 


SCCH information and distribution on 18th frame information 
element contents 


208 


16.10.47 


- 


Void 


208a 


16.10.47a 


16.83 


Start of direct mode operation cause information element 
contents 


209 


16.10.48 


16.84 


Status downlink information element content 


209a 


16.10.48a 


16.85 


Status uplink information element content 


210 


16.10.49 


16.86 


Subscriber class information element 


211 


16.10.50 


- 


Void 


212 


16.10.51 


16.87 


Type 3/4 element identifier information element contents 


213 


16.10.52 


16.88 


(V)GSSI information element contents 


213a 


16.10.53 


16.89 


Zero bit information element contents 


214 


17.2 


17.1 


MLE SAPs 


215 


17.3.1 


17.2 


Primitives and parameters at the LMM-SAP 


216 


17.3.3 


17.3 


Primitives and parameters at the LCMC-SAP 
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217 


17.3.5 


17.4 


Primitives and parameters at the LTPD-SAP 


218 


17.3.7 


- 


Void 


219 


17.3.7 


- 


Void 


220 


18.4.1.3 


18.1 


IVILE service PDU layout 


221 


18.4.1.3 


- 


Void 


222 


18.4.1.4.1 


18.2 


D-NWRK-BROADCAST PDU 


223 


18.4.1.4.2 


18.3 


D-NEW-CELL PDU 


224 


18.4.1.4.3 


18.4 


D-PREPARE-FAIL PDU 


225 


18.4.1.4.4 


18.5 


D-RESTORE-ACK PDU 


226 


18.4.1.4.5 


18.6 


D-RESTORE-FAIL PDU 


227 


18.4.1.4.6 


18.7 


U-PREPARE PDU 


228 


18.4.1.4.7 


18.8 


U-RESTORE PDU 


229 


18.4.2.1 


18.9 


D-MLE-SYNC PDU 


230 


18.4.2.2 


18.10 


D-MLE-SYSINFO PDU 


231 


18.5.1 


18.11 


Cell reselection types supported information element 


232 


18.5.2 


18.12 


BS Service details information element 


233 


18.5.3 


18.13 


Cell identifier information element 


234 


18.5.4 


18.14 


Cell re-select parameters information element 


235 


18.5.5 


18.15 


Cell service level information element 


236 


18.5.6 


18.16 


Channel command valid element 


237 


18.5.7 


18.17 


Fail cause information element 


238 


18.5.8 


18.18 


Late entry supported information element 


239 


18.5.9 


18.19 


LA information element 


240 


18.5.10 


18.20 


IVIain carrier number information element 


241 


18.5.11 


18.21 


IVIain carrier number extension information element 


242 


18.5.12 


18.22 


Minimum RX access level information element 


243 


18.5.13 


18.23 


Maximum MS transmit power information element 


244 


18.5.14 


18.24 


MCC information element 


245 


18.5.15 


18.25 


MNC information element 


246 


18.5.16 


18.26 


Neighbour cell broadcast information element 


247 


18.5.17 


18.27 


Neighbour cell information information element 


248 


18.5.18 


18.28 


Neighbour cell synchronized information element 


249 


18.5.19 


18.29 


Number of neighbour cells information element 


250 


18.5.20 


18.30 


PDU type information element 


251 


18.5.21 


18.31 


Protocol discriminator information element 


252 


18.5.22 


18.32 


Subscriber class information element 


253 


18.5.23 


18.33 


TDMA frame offset information element 


254 


18.5.24 


18.34 


TETRA network time information element 


255 


18.5.25 


18.35 


Timeshare cell information information element 


256 


19.2.4.4 


19.1 


Mapping between TMx-SAP and MAC logical channels 


257 


19.2.4.4 


19.2 


Mapping between MAC logical channels and physical layer 
bursts 


258 


20.2.4.19 


20.1 


Definition of half slot importance 


259 


20.2.4.31 


20.2 


Throughput for constant delay services 


260 


20.2.4.31 


20.3 


Throughput for variable delay services 


261 


20.2.4.31 


20.4 


Residual error rate 


262 


20.2.4.31 


20.5 


Transfer failure probability 


263 


20.2.4.31 


20.6 


NC Release failure probability 


264 


20.2.4.33 


20.7 


Reports at TMA-, TMC-, TLA- and TLC-SAPs 


265 


20.3.1 


20.8 


Services provided at the TLA-SAP 


266 


20.3.1 


20.9 


Data transfer relationships available in the LLC 


267 


20.3.2 


20.10 


Services provided at the TLB-SAP 


268 


20.3.3 


20.11 


Services provided at the TLC-SAP 


- 


20.3.3a 


20.12 


Services provided at the TLE-SAP 


- 


20.3.4 


20.13 


TLE-SAP service primitives 


269 


20.3.4 


20.14 


TLA-SAP service primitives 


270 


20.3.4 


20.15 


TLB-SAP service primitives 


271 


20.3.4 


20.16 


TLC-SAP service primitives 


272 


20.3.5.1.1 


20.17 


Parameters used in the TL-CANCEL primitive 


273 


20.3.5.1.2 


20.18 


Parameters used in the TL-CONNECT primitive 


274 


20.3.5.1.3 


20.19 


Parameters used in the TL-DATA primitive for advanced link 
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275 


20.3.5.1.4 


20.20 


Parameters used in the TL-DATA primitive for basic link 


276 


20.3.5.1.5 


20.21 


Parameters used in the TL-DISCONNECT primitive 


276A 


20.3.5.1.5a 


20.22 


Parameters used in the TL-RECEIVE primitive (TLA-SAP) 


276A 


20.3.5.1.6 


20.23 


Parameters used in the TL-RECONNECT primitive 


277 


20.3.5.1.7 


20.24 


Parameters used in the TL-RELEASE primitive 


278 


20.3.5.1.8 


20.25 


Parameters used in the TL-REPORT primitive (TLA-SAP) 


279 


20.3.5.1.9 


20.26 


Parameters used in the TL-UNITDATA primitive in basic linl< 


280 


20.3.5.1.9 


20.27 


Parameters used in the TL-UNITDATA primitive in advanced 
link 


281 


20.3.5.3.1 


20.28 


Parameters used in the TL-SYNC primitive 


282 


20.3.5.3.2 


20.29 


Parameters used in the TL-SYSINFO primitive 


283 


20.3.5.4.1 


20.30 


Parameters used in the TL-CONFIGURE primitive 


284 


20.3.5.4.2 


20.31 


Parameters used in the TL-MEASUREMENT primitive 


285 


20.3.5.4.3 


20.32 


Parameters used in the TL-IVIONITOR primitive 


286 


20.3.5.4.4 


20.33 


Parameters used in the TL-MONITOR-LIST primitive 


287 


20.3.5.4.5 


20.34 


Parameters used in the TL-REPORT primitive (TLC-SAP) 


288 


20.3.5.4.6 


20.35 


Parameters used in the TL-SCAN primitive 


289 


20.3.5.4.7 


20.36 


Parameters used in the TL-SCAN-REPORT primitive 


290 


20.3.5.4.8 


20.37 


Parameters used in the TL-SELECT primitive 


- 


20.3.5.5.1 


20.38 


Parameters used in the TLE-CANCEL primitive 


- 


20.3.5.5.2 


20.39 


Parameters used in the TLE-REPORT primitive 


- 


20.3.5.5.3 


20.40 


Parameters used in the TLE-UNITDATA primitive 


291 


20.4 


20.41 


TMA-SAP service primitives 


292 


20.4 


20.42 


TIVIB-SAP service primitives 


293 


20.4 


20.43 


TMC-SAP service primitives 


294 


20.4 


20.44 


TIVID-SAP service primitives 


295 


20.4.1.1.1 


20.45 


Parameters used in the TIVIA-CANCEL primitive 


296 


20.4.1.1.2 


20.46 


Parameters used in the TMA-RELEASE primitive 


297 


20.4.1.1.3 


20.47 


Parameters used in the TMA-REPORT primitive 


298 


20.4.1.1.4 


20.48 


Parameters used in the TMA-UNITDATA primitive 


299 


20.4.1.3 


20.49 


Correspondence between IVIAC and LLC at the TMA-SAP and 
TLA-SAP 


300 


20.4.2 


20.50 


Correspondence between MAC and LLC at the TMB-SAP and 
TLB-SAP 


SODA 


20.4.3 


20.51 


Parameters used in the TMC-CONFIGURE request primitive 


301 


20.4.3 


20.52 


Correspondence between MAC and LLC at the TMC-SAP and 
TLC-SAP 


302 


20.4.4.1.1 


20.53 


Parameters used in the TMD-REPORT primitive 


303 


20.4.4.1.2 


20.54 


Parameters used in the TMD-UNITDATA primitive 


304 


21.2.1 


21.1 


Definition of LLC PDU types 


- 


21.2.1 


21.2 


Definition of layer 2 signalling PDU subtypes for LLC PDU type 
IIIO2 


305 


21.2.2.1 


21.3 


BL-ACK PDU without PCS contents 


306 


21.2.2.1 


21.4 


BL-ACK PDU with PCS contents 


307 


21.2.2.2 


21.5 


BL-ADATA PDU without PCS contents 


308 


21.2.2.2 


21.6 


BL-ADATA PDU with PCS contents 


309 


21.2.2.3 


21.7 


BL-DATA PDU without PCS contents 


310 


21.2.2.3 


21.8 


BL-DATA PDU with PCS contents 


311 


21.2.2.4 


21.9 


BL-UDATA PDU without PCS contents 


312 


21.2.2.4 


21 


10 


BL-UDATA PDU with PCS contents 


313 


21.2.3.1 


21 


11 


AL-ACK and AL-RNR PDUs contents 


314 


21.2.3.1 


21 


12 


Acknowledgement block information element contents 


315 


21.2.3.2 


21 


13 


AL-FINAL and AL-FINAL-AR PDUs contents 


316 


21.2.3.3 


21 


14 


AL-DATA and AL-DATA-AR PDUs contents 


317 


21.2.3.4 


21 


15 


AL-DISC PDU contents 


317a 


21.2.3.4a 


21 


16 


AL-RECONNECT PDU contents 


318 


21.2.3.5 


21 


17 


AL-SETUP PDU contents 


319 


21.2.3.6 


21 


18 


AL-UDATA PDU contents 


320 


21.2.3.7 


21 


19 


AL-UFINAL PDU contents 


- 


21.2.4.1 


21 


20 


L2-DATA-PRI0RITY PDU contents 


- 


21.2.4.1 


21 


21 


Data priority block information element contents 
in L2-DATA-PRI0RITY PDU 
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Name 


321 


21.4.1 


21.22 


MAC PDU types for SCH/F, SCH/HD and STCH 


322 


21.4.1 


21.23 


MAC PDU Types for SCH/HU 


323 


21.4.2.1 


21.24 


MAC-ACCESS PDU contents 


324 


21.4.2.1 


21.25 


Length of MAC-ACCESS PDU lieader and SDU 


325 


21.4.2.2 


21.26 


MAC-END-HU PDU contents 


326 


21.4.2.3 


21.27 


MAC-DATA PDU contents 


327 


21.4.2.4 


21.28 


MAC-FRAG (uplinl<) PDU contents 


328 


21.4.2.5 


21.29 


MAC-END (uplinl<) PDU contents 


329 


21.4.3.1 


21.30 


MAC-RESOURCE PDU contents 


330 


21.4.3.2 


21.31 


MAC-FRAG (downlink) PDU contents 


331 


21.4.3.3 


21.32 


MAC-END (downlink) PDU contents 


332 


21.4.4 


21.33 


Broadcast PDU contents 


333 


21.4.4.1 


21.34 


Broadcast PDU contents 


334 


21.4.4.1 


21.35 


Default definition for access code A information element 
contents 


334a 


21.4.4.1 


21.36 


Extended services broadcast information element 


- 


21.4.4.1 


21.37 


Extended services broadcast section 1 information element 


- 


21.4.4.1 


21.38 


Extended services broadcast section 2 information element 


- 


21.4.4.1 


21.39 


Extended services broadcast section 3 information element 


- 


21.4.4.1 


21.40 


Extended services broadcast section 4 information element 


335 


21.4.4.2 


21.41 


SYNC PDU contents 


336 


21.4.4.3 


21.42 


Access define PDU contents 


337 


21.4.5 


21.43 


MAC-U-SIGNAL PDU contents 


338 


21.4.7 


21.44 


ACCESS-ASSIGN PDU contents for frames 1 to 17 


339 


21.4.7 


21.45 


ACCESS-ASSIGN PDU contents for frame 18 


340 


21.5.1 


21.46 


Access field information element contents 


341 


21.5.2 


21.47 


Channel allocation information element contents 


342 


21.5.3 


21.48 


Power control information element contents 


343 


21.5.4 


21.49 


Reservation requirement information element contents 


344 


21.5.5 


21.50 


TS COMMON FRAMES information element contents 


345 


21.5.6 


21.51 


Slot granting information element contents 


346 


23.2.1 


23.1 


Correspondence between the upper and lower MAC at the 
TMV-SAP 


347 


23.2.1 


23.2 


Parameters used in the TMV-UNITDATA primitive 


348 


23.2.2 


23.3 


Mapping of the MAC PDU onto the logical channels 


349 


23.7.6 


23.4 


Definition of the Economy Groups and duration 


350 


Void 


- 


Void 


351 


Void 


- 


Void 


352 


Void 


- 


Void 


353 


Void 


- 


Void 


354 


Void 


- 


Void 


355 


Void 


- 


Void 


356 


Void 


- 


Void 


357 


Void 


- 


Void 


358 


28.2.3.1 


28.1 


Parameters for the primitive SN-DATA 


359 


28.2.3.1 


28.2 


Parameters for the primitive SN-DELIVERY 


360 


28.2.3.1 


28.3 


Parameters for the primitive SN-NSAPI ALLOC 


361 


28.2.3.1 


28.4 


Parameters for the primitive SN-NSAPI DEALLOC 


362 


28.2.3.1 


28.5 


Parameters for the primitive SN-QOS 


363 


28.2.3.1 


28.6 


Parameters for the primitive SN-UNITDATA 


364 


28.2.3.1 


28.7 


Parameters for the primitive SN-PAGE 


365 


28.2.5 


28.8 


MS State Transition Table 


366 


28.2.5 


28.9 


SwMI State Transition table 


366A 


28.3.3.4 


28.10 


Packet data MS types and other services 


367 


28.3.4.1 


28.11 


Logical link usage by SN-PDUs 


368 


28.3.4.1 


28.12 


Usage of basic link unacknowledged and acknowledged 
services 


369 


28.3.4.2 


28.13 


Message sent by SwMI in response to SN-RECONNECT from 
MS 


370 


28.3.5.3.2 


28.14 


Compressed header format 


370A 


28.3.5.4.3 


28.15 


BSD compressed data format 


37GB 


28.3.5.4.4 


28.16 


Predictor compressed data format 
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371 


28.4.1 


28.17 


PDU priority for SN-PDUs 


372 


28.4.4.1 


28.18 


SN-ACTIVATE PDF CONTEXT ACCEPT PDU contents 


373 


28.4.4.2 


28.19 


SN-ACTIVATE PDP CONTEXT DEMAND PDU contents 


374 


28.4.4.3 


28.20 


SN-ACTIVATE PDP CONTEXT REJECT PDU contents 


375 


28.4.4.4 


28.21 


SN-DATA PDU contents 


376 


28.4.4.5 


28.22 


SN-DATA TRANSMIT REQUEST PDU contents 


377 


28.4.4.6 


28.23 


SN-DATA TRANSMIT RESPONSE PDU contents 


378 


28.4.4.7 


28.24 


SN-DEACTIVATE PDP CONTEXT DEMAND PDU contents 


379 


28.4.4.8 


28.25 


SN-DEACTIVATE PDP CONTEXT ACCEPT PDU contents 


380 


28.4.4.9 


28.26 


SN-END OF DATA PDU contents 


380A 


28.4.4.10 


28.27 


SN-NOT SUPPORTED PDU contents 


381 


28.4.4.11 


28.28 


SN-PAGE REOUEST PDU contents 


382 


28.4.4.12 


28.29 


SN-PAGE RESPONSE PDU contents 


383 


28.4.4.13 


28.30 


SN-RECONNECT PDU contents 


384 


28.4.4.14 


28.31 


SN-UNITDATA PDU contents 


385 


28.4.5.1 


28.32 


Accept/Reject information element contents 


385a 


28.4.5.2 


28.33 


Access point name index information element contents 


386 


28.4.5.3 


28.34 


Activation reject cause information element contents 


387 


28.4.5.4 


28.35 


Address Type Identifier in Demand information element 
contents 


387a 


28.4.5.5 


28.36 


BSD data compression parameters information element 
contents 


387b 


28.4.5.6 


28.37 


BSD compression version information element contents 


387c 


28.4.5.7 


28.38 


BSD dictionary size information element contents 


388 


28.4.5.8 


28.39 


Data to Send information element contents 


389 


28.4.5.9 


28.40 


DCOMP information element contents 


390 


28.4.5.10 


28.41 


DCOMP negotiation information element contents 


391 


28.4.5.11 


28.42 


Deactivation type information element contents 


391a 


28.4.5.11 


- 




391 B 


28.4.5.12 


28.43 


Enhanced service information element contents 


391 C 


28.4.5.13 


28.44 


Immediate service change information element contents 


392 


28.4.5.14 


28.45 


IP address IPv4 information element contents 


392a 


28.4.5.15 


28.46 


Largest header size in octets that may be compressed 
information element contents 


392B 


28.4.5.16 


28.47 


Logical link status information element contents 


392C 


28.4.5.16 


- 




392D 


28.4.5.17 


28.48 


Maximum interval between full headers information element 
contents 


392E 


28.4.5.18 


28.49 


Maximum time interval between full headers information 
element contents 


393 


28.4.5.19 


28.50 


Maximum Transmission Unit information element contents 


393a 


29.4.5.20 


28.51 


Not supported SN PDU type information element contents 


394 


29.4.5.21 


28.52 


N-PDU information element contents 


395 


29.4.5.22 


28.53 


NSAPI information element contents 


395a 


29.4.5.23 


28.54 


Number of compression state slots, TCP information element 
contents 


395B 


29.4.5.24 


28.55 


Number of compression state slots, non-TCP information 
element contents 


396 


29.4.5.25 


28.56 


Number of VJ compression state slots information element 
contents 


397 


29.4.5.26 


28.57 


Packet data MS Type information element contents 


398 


29.4.5.27 


28.58 


PCOMP information element contents 


399 


29.4.5.28 


28.59 


PCOMP negotiation information element contents 


400 


29.4.5.29 


28.60 


PD service status information element contents 


401 


29.4.5.30 


28.61 


PDU priority information element contents 


402 


29.4.5.31 


28.62 


Protocol configuration options information element contents 


403 


29.4.5.32 


28.63 


READY timer information element contents 


404 


29.4.5.33 


28.64 


Reply requested information element contents 


404a 


29.4.5.34 


28.65 


Resource request information element contents 


405 


29.4.5.35 


28.66 


RESPONSE WAIT timer information element contents 


406 


29.4.5.36 


28.67 


SNDCP version information element contents 


407 


29.4.5.37 


28.68 


SNDCP endpoint identifier information element contents 
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408 


29.4.5.38 


28.69 


SN PDU type information element contents 


409 


29.4.5.39 


28.70 


STANDBY timer information element contents 


410 


29.4.5.40 


28.71 


SwIVII IPv6 Information information element contents 


411 


29.4.5.41 


28.72 


SwMI IVIobile IPv4 Information information element contents 


412 


29.4.5.42 


28.73 


Transmit reject cause information element contents 


413 


29.4.5.43 


28.74 


Type Identifier in Accept information element contents 


414 


29.4.5.44 


28.75 


Type 3 element identifier information element contents 


415 


29.4.5.45 


28.76 


ITU-T Recommendation V.42bis data compression request 
parameters information element contents 


416 


29.4.5.46 


28.77 


ITU-T Recommendation V.42bis data compression parameters 
element contents 


417 


29.4.5.47 


28.78 


ITU-T Recommendation V.42bis maximum string length 
element contents 


418 


29.4.5.48 


28.79 


ITU-T Recommendation V.42bis number of codewords 
element contents 


419 


29.2.2 


29.1 


Parameters for the TLSDS-TRANSFER primitive without store 
and forward addressing 


420 


29.2.2 


29.2 


Parameters for the TLSDS-TRANSFER primitive with store 
and forward addressing 


421 


29.2.2 


29.3 


Parameters for the TLSDS-REPORT primitive (no store and 
forward) 


422 


29.2.2 


29.4 


Parameters for the TLSDS-REPORT primitive (store and 
forward) 


423 


29.2.2 


29.5 


Parameters for the TLSDS-ACK primitive (no store and 
forward) 


424 


29.2.2 


29.6 


Parameters for the TLSDS-ACK primitive (store and forward) 


425 


29.3.1 


29.7 


IVIS1 to MS2 transparent 


426 


29.3.1 


29.8 


MSI to l\/IS2 using forward address 


427 


29.3.1 


29.9 


IV1S1 to MS2/user 2 using forward address via a gateway 


428 


29.4.1 


29.10 


PDU layout 


429 


29.4.2.1 


29.11 


SDS-ACK PDU contents 


430 


29.4.2.2 


29.12 


SDS-REPORT PDU contents 


431 


29.4.2.3 


29.13 


SDS-SHORT REPORT PDU contents 


432 


29.4.2.4 


29.14 


SDS-TRANSFER PDU contents 


433 


29.4.3.1 


29.15 


Acknowledgement required information element contents 


434 


29.4.3.2 


29.16 


Delivery status information element contents 


435 


29.4.3.3 


29.17 


Delivery report request information element contents 


436 


29.4.3.5 


29.18 


Forward address type information element contents 


437 


29.4.3.7 


29.19 


Message reference information elements contents 


438 


29.4.3.8 


29.20 


Message type information element contents 


439 


29.4.3.9 


29.21 


Protocol identifier information element contents 


440 


29.4.3.10 


29.22 


Service selection/ short form report information element 
contents 


441 


29.4.3.11 


29.23 


Short report type information element contents 


442 


29.4.3.12 


29.24 


Storage information element contents 


443 


29.4.3.14 


29.25 


Validity period information element contents 


444 


29.5.1.2 


29.26 


Standardized "simple" protocol PDU contents 


445 


29.5.2.3 


29.27 


Simple text messaging PDU contents 


446 


29.5.3.3 


29.28 


Text message transfer SDU contents 


447 


29.5.4.1 


29.29 


Text coding scheme information element contents 


448 


29.5.4.2 


29.30 


7-bit character presentation 


448a 


29.5.4.2 


29.31 


One 7-bit character in one octet 


448b 


29.5.4.2 


29.32 


Two 7-bit characters in two octets 


448c 


29.5.4.2 


29.33 


Seven 7-bit characters in seven octets 


449 


29.5.4.2 


29.34 


Character packing for 7-bit alphabet 


449a 


29.5.4.2 


29.35 


8-bit character presentation 


449B 


29.5.4.2 


29.36 


Character packing for 8-bit alphabet 


449C 


29.5.4.2 


29.37 


1 6-bit character presentation 


449D 


29.5.4.2 


29.38 


Character packing for 16-bit alphabet 


450 


29.5.4.3 


29.39 


Alphabet table for GSM 7-bit alphabet 


451 


29.5.4.4 


29.40 


Time stamp information element contents 


452 


29.5.4.5 


29.41 


Timestamp used information element contents 
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453 


29.5.5.3 


29.42 


Simple GPS PDU contents 


454 


29.5.6.3 


29.43 


GPS SDU contents 


455 


29.5.7 


29.44 


GPS coding scheme information element contents 


- 


29.5.9.3 


29.45 


UDH transfer SDU contents 


- 


29.5.9.4.1 


29.46 


User Data Header information element information element 
contents 


- 


29.5.9.4.1 


29.47 


UDH information element ID contents 


- 


29.5.10.3 


29.48 


Concatenated text message transfer SDU contents 


- 


29.5.12.6 


29.49 


SDS type 4 user data contents 



Table M.2 compares figure numbers of EN 300 392-2 versions up to V2.4.2 and figure numbers of TS 100 392-2 and 
EN 300 392-2 V2.5.1, V2.5.2 and V2.6.1. In the later versions than TS 100 392-2 and EN 300 392-2 V2.5.1, V2.5.2 and 
V2.6.1 the figure numbers may be different than those in the table M.2. Table M.2 identifies by bold font figure 
numbers that are referenced to from other clauses than those in each editorial sub-part of EN 300 392-2 or from other 
TETRA specifications or standards at the time of drafting of the present document. That marking may not be complete. 

Table M.2: Figure numbering 



Versions 
V2.4.2and V2.4.1 
Figure Clause 


Versions 

V2.5.1,V2.5.2and 

V2.6.1 

Clause.figure 


Name 


1 


4.3 


4.1 


Reference configuration 


2 


4.5.1 


4.2 


V+D TDIVIA structure 


3 


5.4 


5.1 


Modulation symbol constellation and possible transitions 


4 


5.7 


5.2 


Block diagram of the modulation process 


5 


6.3 


6.1 


Reference interconnection of transmitters and receivers at BS 


6 


6.4.2.1 


6.2 


Schematic presentation of transmitter states 


7 


6.4.5 


6.3 


Transmit level versus time mask 


8 


8.2.1 


8.1 


Interfaces in the error control structure 


9 


8.3 


8.2 


Error control structure for V+D logical channels (part 1) 


10 


8.3 


8.3 


Error control structure for V+D logical channels (part 2) 


11 


9.3.2 


9.1 


TDMA structure 


12 


9.4.4.1 


9.2 


Types of bursts 


13 


11.3.1 


11.1 


GC services provided at TNCC-SAP MS-side 


14 


11.4 


11.2 


State transition diagram for one instance at the CC SAP 


15 


12.3.1 


- 


Void 


16 


13.3.1 


13.1 


SDS provided at TNSDS-SAP (MS-side) 


17 


13.3.5 


13.2 


Service state diagram for the mobile terminated short data 
message 


18 


14.2 


14.1 


System view 


19 


14.2.1 


14.2 


Block view of CMCE-MS 


20 


14.4.1 


14.3 


State transition diagram for the PC sub-entity 


21 


14.4.2 


14.4 


State transition diagram for the CC sub-entity 


22 


14.4.2 


14.5 


Sub state transition diagram for the CALL-ACTIVE state 


23 


14.4.2 


14.6 


Sub state transition diagram for the MT-CALL-SETUP state 


24 


14.4.3 


14.7 


State transition diagram for the SS sub-entity 


25 


14.4.4 


14.8 


State transition diagram for the SDS 


26 


14.5.1.1 


14.9 


Individual call set-up scenario using on/off hook signalling 


27 


14.5.1.1 


14.10 


Individual call set-up scenario using direct set-up signalling 


28 


14.5.1.1.5 


14.11 


Individual call set-up phase - called user application rejects 
the call 


29 


14.5.1.2.1 


14.12 


Individual call request-to-transmit 


30 


14.5.1.2.4 


14.13 


Individual call - successful call restoration 


31 


14.5.1.2.4 


14.14 


Individual call - unsuccessful call restoration 


32 


14.5.1.3 


14.15 


Individual call request-to-disconnect 


33 


14.5.2.1 


14.16 


Group call - set-up phase 


34 


14.5.2.1 


14.17 


Acknowledged group call - set-up phase 


35 


14.5.2.2.1 


14.18 


Group call - request-to-transmit 


36 


14.5.2.2.4 


14.19 


Group call - successful call restoration 
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37 


14.5.2.2.4 


14.20 


Group call - unsuccessful call restoration 


38 


14.5.2.3 


14.21 


Group call - request-to-disconnect 


39 


14.5.2.3 


14.22 


Group call - group member leaves ongoing group call 


40 


14.5.4 


14.23 


Internal view of SS sub-entity 


41 


15.3.1 


15.1 


Services provided at TNMM-SAP/MS-side 


42 


15.3.6 


15.2 


MM service state diagram (sheet 1 of 4) 


42 


15.3.6 


15.3 


MM service state diagram (sheet 2 of 4) 


42 


15.3.6 


15.4 


MM service state diagram (sheet 3 of 4) 


42 


15.3.6 


15.5 


MM service state diagram (sheet 4 of 4) 


43 


15.3.6 


- 


Void 


44 


15.3.6 


- 


Void 


45 


15.3.6 


- 


Void 


46 


16.3 


16.1 


MM main functions on the MS 


47 


16.3.1.1 


16.2 


MM Activation procedure, successful cell selection 


48 


16.4.1.1 


16.3 


MLE initiated registration in cases a), b) and d) 


49 


16.4.1.2 


16.4 


MLE initiated forward registration 


50 


16.4.2 


16.5 


User application initiated registration in cases a) and b) 


51 


16.4.3 


16.6 


Infrastructure initiated registration 


52 


16.4.3 


- 


Void 


53 


16.4.3 


- 


Void 


54 


16.6.1 


16.7 


De-registration of MS (detach) 


55 


16.7.1 


16.8 


Change energy economy mode 


56 


16.8.1 


16.9 


SwMI initiated attachment/detachment of group identities 


57 


16.8.2 


16.10 


MS initiated attachment/detachment of group identities, 
acknowledgement requested 


58 


16.8.3 


16.11 


SwMI initiated group report 


59a 


16.8.4 


16.12 


MS initiated group report 


59B 


17.2 


17.1 


Relationship between a service user and a service provider 


60 


17.2 


17.2 


Services relationships offered by the MLE in the air interface 


61 


17.3.1 


17.3 


LMM-SAP state transition diagram 


62 


17.3.3 


17.4 


State transition diagram of LGMC-SAP 


63 


17.3.5 


17.5 


State transition diagram of LTPD-SAP 


64 


17.3.7 


- 


Void 


65 


18.2.1 


18.1 


The MLE (sub-layer 3.1) in the MS protocol stack 


66 


18.2.8 


18.2 


Primitive time sequence at the LTPD-SAP 


67 


18.2.8 


18.3 


Primitive time sequence at the LMM-SAP 


68 


18.2.8 


18.4 


Primitive time sequence at the LGMC-SAP 


69 


18.3.1 


18.5 


MLE functional model 


70 


18.3.4.7.1 


18.6 


Decision tree to choose reselection type 


71 


18.3.4.7.3 


18.7 


Unannounced cell reselection procedure 


72 


18.3.4.7.4 


18.8 


Announced type 3 cell reselection procedure 


73 


18.3.4.7.5 


18.9 


Announced type 2 cell reselection procedure 


74 


18.3.4.7.6 


18.10 


Announced type 1 cell reselection procedure 


75 


19.2.1 


19.1 


Layer 2 reference architecture 


76 


19.2.2 


19.2 


Layer 2 data structure for basic link (typically layer 3 signalling 
messages) 


77 


19.2.2 


19.3 


Layer 2 data structure for advanced link (e.g. packet data) 


78 


19.2.2.3 


19.4 


Segmentation and fragmentation in the DLL 


79 


19.2.2.3 


19.5 


Fragmentation of long SDU in the MAC layer 


80 


19.2.3 


19.6 


DLL protocol illustration for the MS side 


81 


19.2.4.4 


19.7 


MAC sub-layers and logical channels for MS uplink 
transmission 


82 


19.2.4.4 


19.8 


MAC sub-layers and logical channels for MS downlink 
reception 


83 


19.4.2.4 


19.9 


Configuration in signalling and packet mode 


84 


19.4.2.4 


19.10 


Configuration in traffic mode for frames 1 to 17 


85 


19.4.4 


19.11 


Selection of the configuration for the current mode of 
operation 
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86 


19.5 


19.12 


Primitives and PDUs on tine calling MS air interface for an 
individual call with direct set-up signalling - Calling MS side 


87 


19.5 


19.13 


Primitives and PDUs on the calling MS air interface for an 
individual call with direct set-up signalling - SwMI side 


88 


19.5 


19.14 


Primitives and PDUs on the called MS air interface for an 
individual call with direct set-up signalling - SwMI side 


89 


19.5 


19.15 


Primitives and PDUs on the called MS air interface for an 
individual call with direct set-up signalling - Called MS side 


90 


20.2.1 


20.1 


SAPs at the MLE-LLC boundary 


91 


20.3.6 


20.2 


State transition diagram in basic link at TL-SAP 


92 


20.3.7 


20.3 


State transition in connection mode at MLE-LLC SAP 
(advanced link) 


93 


21.1.2 


21.1 


Construction of an LLC PDU (shown with optional PCS) 


94 


21 


1.2.2 


21.2 


General format of an LLC header before the TL-SDU content 


95 


21 


1.3.1 


21.3 


General format of the MAC PDU 


96 


21 


1.3.2 


21.4 


General format of a MAC header 


97 


21 


1.3.2 


21.5 


Association of several MAC PDU in one MAC block 


98 


21 


1.4.1 


21.6 


Building of DLL PDU (with no fragmentation) 


99 


21 


1.4.1 


21.7 


MAC fragmentation of a long TM-SDU 


100 


21 


1.4.2 


21.8 


Segmentation provided by the advanced link 


101 


22.1.2 


22.1 


LLC relations 


102 


22.1.2 


22.2 


LLC protocol structure 


103 


22.2.1.1 


22.3 


Basic link PDU exchange with acknowledgement carrying a 
layer 3 message 


104 


22.2.1.1 


22.4 


Basic link data transfer and acknowledgement with a layer 3 
message 


105 


22.2.1.1 


22.5 


Basic link PDU exchange with LLC acknowledgement with a 
delayed response 


106 


22.2.1.1 


22.6 


Basic link data transfer and acknowledgement with a delayed 
layer 3 response 


107 


22.2.1.1 


22.7 


Concurrent independent message exchange in both directions 


108 


22.2.1.1 


22.8 


Concurrent independent message exchange in both directions 


109 


22.2.1.2 


22.9 


PDU exchange in unacknowledged mode 


110 


22.2.1.2 


22.10 


Basic link data transfer in unacknowledged mode 


111 


22.2.1.3 


22.11 


Basic link data transfer with presence indication 


112 


22.2.1.3 


22.12 


Basic link data transfer with presence indication 


113 


22.2.2.1 


22.13 


PDU setting up the advanced link 


114 


22.2.2.1 


22.14 


Advanced link set-up 


115 


22.2.2.1 


22.15 


Advanced link set-up to a lower quality of service 


116 


22.2.2.1 


22.16 


Simultaneous advanced link set-up 


117 


22.2.2.1 


22.17 


Simultaneous advanced link set-up with different QoS 


118 


22.2.2.1 


22.18 


Simultaneous advanced link set-up with different QoS 


119 


22.2.2.1 


22.19 


Unsupported service indication 


120 


22.2.2.2 


22.20 


Unacknowledged transfer mode set-up of the advanced link 


121 


22.2.2.2 


22.21 


Unacknowledged transfer mode set-up of the advanced link 
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22.22 


PDU exchange in a unidirectional transfer 


123 


22.2.2.3 


22.23 


PDU exchange in a unidirectional transfer 
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A longer PDU transfer 
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22.25 


Bi-directional data transfer 
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22.26 


Bi-directional PDU transfer 
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22.27 


PDU sending in a unidirectional transfer 
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22.28 


PDU sending in a unidirectional transfer 
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22.2.2.5 


22.29 


PDU exchange for forced acknowledgement 
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22.2.2.5 


22.30 


Forced acknowledgement 
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22.2.2.6 


22.31 


Selective re-transmission example 
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Flow control PDU exchange 
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Flow control 
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PDU exchange for reconnection the advanced link 
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22.35 


Reconnection of an advanced link 
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PDU exchange for releasing the advanced link 
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Disconnection of an advanced link 
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PDU exchange for releasing the unacknowledged advanced 
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V+D air interface addressing 
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Usage of TETRA packet data for MTO WAP application 


183 


28.1 
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MS 
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Acknowledged service, SwMI rejects request 
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28.3.5.2 


28.32 


Unacknowledged service, data from SwMI to MS 
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ITU-T Recommendation V.42bis [27] data compression 
function 
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28.34 
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28.3.7 
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A successful authentication with CHAP 
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SDS-TL position in TETRA protocol stack 


217 
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218 
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29.3 


Layer 2 Acknowledgement 
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29.3.2.2 


29.4 


"Message received" end-to-end acknowledgement 


220 


29.3.2.2 


29.5 


"Message consumed" end-to-end acknowledgement 


221 


29.3.3.1 


29.6 


SDS message transfer with end-to-end acknowledgement, 
SwMI transparent 


222 


29.3.3.1 


29.7 


SDS message transfer with end-to-end acknowledgement, 
SwMI does store and forward 
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29.8 


SDS message transfer with consumed acknowledge, SwMI 
modifies requested reports 
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29.5.12.3.2 


29.9 


LIP position in TETRA protocol stack 
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Annex N (informative): 

Example for coding of SDS Transfer SDU with UDH 

information elements 

This annex lists an example for using the UDH information elements within a SDS Transfer SDU. It shows the basic 
procedure to decode UDH information. 

N.1 Multiple Information Elements with Network Layer 
User Data (Text Message) 

This example shows how to send information for 3 different fictive user applications and a text message using one 
SDU. Lets assume the following: 

1) Three dimensional location information shall be send including x, y, z coordinates. UDH information element 
ID value shall be OxEl . The definition for the data of that protocol shall be 2 bytes for each x, y and z 
coordinates value. 

2) Star time information shall be send including standard star time format. UDH information element ID value 
shall be 0xE2. The definition for the data of that protocol shall be 3 bytes star time value and 4 bytes universe 
ID. 

3) Speed information shall be send including speed over ground. UDH information element ID value shall be 
OxE3. The definition for the data of that protocol shall be 2 bytes for speed value. 

4) Text message shall be send including 1 1 bytes Latin- 1 coded characters. 
The resulting SDU would look as presented in table N.L 

Table N.I : Example transfer SDU for multiple UDH information elements with text message 



Information element 


Length 


Value 


Remark 


Time stamp used 


1 


0x00 


No time stamp used 


Text coding scheme 


7 


0x01 


Latin-1 coding for text message 


User data header length 


8 


0x15 


21 byte UDH 


UDH information element ID 


8 


OxEl 


Thee dimensional location 
information 


UDH information element length 


8 


0x06 


6 bytes (2 x, 2 y , 2 z) 


X-Coordinate 


16 


0x0010 


16 cm 


Y-Coordinate 


16 


0x0020 


32 cm 


Z-Coordinate 


16 


0x0030 


48 cm 


UDH information element ID 


8 


0xE2 


Star time information 


UDH information element length 


8 


0x07 


7 bytes (3 time, 4 universe. ID) 


Star Time 


24 


0xD91122 


217.17.34 units 


Universe ID 


32 


0x00112233 


Andromeda 


UDH information element ID 


8 


0xE3 


Speed information 


UDH information element length 


8 


0x02 


2 bytes speed 


Speed 


16 


0x001 1 


17km/h 


Text Message 


88 


"The is text" 


11 bytes Latin-1 coded text 



All these information elements or information element sets respectively are independant from each other. Since this 
SDU will be sent using the PI Message with User Data Header the receiving application would have to support all these 
information elements. That means the application will proceed the following steps: 

1) Get transfer SDU length from lower layer (34 bytes). 

2) Decode Time stamp used and Text coding information elements. Subtract length of both information elements 
(1 byte) from transfer SDU length (34 - 1 = 33). 
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3) Get the UDH information element length value to determine the length of the UDH information element. 
Subtract length of UDH information element length information element (1 byte) from remaining transfer 
SDU length (33 - 1= 32). If the result is equal to the UDH information element length value (21) the SDU does 
not contain Network layer user data and the Text coding IE can be ignored. 

4) Decode the first UDH information element IE ID information element and get the UDH information element 
IE length value (6 bytes). Process the UDH information element U IE Data (x,y,z) information element. 
Subtract complete length of this UDH information element set (2 + 6 bytes) from UDH information element 
length (21 - 8 = 13). Use the UDH information element IE length to find the next UDH information element IE 
ID. 

5) Decode the next UDH information element ID and UDH information element length (7 bytes) information 
elements. Process the UDH information element Data (Star time, Universe ID). Subtract complete length of 
this UDH information element set (2 + 7 bytes) from remaining UDH information element length (13 -9 = 4). 
Use the UDH information element length to find the next UDH information element ID. 

6) Decode the next UDH information element ID and UDH information element length (2 bytes) information 
elements. Process the UDH information elementlE Data (Speed) information element. Subtract complete 
length of this UDH information elementlE set (2 + 2 bytes) from remaining UDH information element length 
(4 - 4 = 0). The remainder is now and that means the end of UDH information element is reached. 

7) Subtract the remainder of UDH information element length value from the remaining transfer SDU length 
(32 - 21 = 11). The result is the length of the text message. Use the Text coding IE to decode the text message. 
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Annex O (normative): 
Air - Ground - Air service 

0.1 Introduction 

Air - Ground - Air service describes the method of operation for Air - Ground - Air service (AGA) in TETRA systems. 
It will serve as a specification for TETRA MSs and SwMI manufacturers to enable them to configure their MSs and 
systems for operation with respect to AGA functionality. 

0.2 Air - Ground - Air service overview 

The AGA service enables TETRA MSs to operate in special situations, where access to the base station is restricted and 
the cell radius must be controlled by round trip delay rather than by RF path loss. Examples of large cells are air cells 
and sea cells. These cases also exemplify the restricted use, since the capacity of these cells is usually small and 
ordinary MSs shall not normally have access to them. This solution uses subscriber class 1 or 2 value "Highly preferred 
cell for subscriber class" as indication of the air cell, see clause O.4. 

NOTE 1: There are also alternative ways to prefer air cells e.g. air cells with value "preferred location areas" may 
be stored in the MS at subscription. That method may not support migration between different networks. 

Because the signal attenuation due to the almost line of sight propagation, the geographical size of an air cell can be 
much larger than that of a normal terrestrial cell. So one air cell covers several terrestrial cells, and air cells may need to 
use specially designated radio channels. Refer to TR 102 021-8 [i.l2]. 

The path delay due to the air cell size may exceed normal system capabilities and clause 0.5 define optional 
modifications to the air BSs and MSs to support longer path delays allowing distances at least to 80 km. 

NOTE 2: Based on the specifications in clause 6.4.5 the maximum allowable path delay for a normal TETRA burst 
structure is 7 symbols (i.e. 14 bits equivalent to the guard period at the end of uplink timeslot). Each 
symbol represents a distance of 8,33 km giving a total maximum cell radius of 58 km. 

Path delay on the air cells could cause the uplink slots from a far and a near MS to partly overlap, refer to clause O.5.I. 
So the base station shall measure the path delay and tell the MS to select a new cell before the delayed signal starts to 
interfere with the next slot. BS may command MS to send periodically signalling or BS may poll the MS to allow BS to 
detect if path delay has been exceeded. 

When air MS loses air cell coverage, it is allowed to use the terrestrial cells, but it should return to an air cell as soon as 
possible. This is achieved by broadcasting AGA subscriber class support (either one of the "highly preferred subscriber 
classes", see clause 0.4.7) on the air cells. If terrestrial MS are not allowed to use air cells, then they will not have a 
matching subscriber class profile. Additionally the SwMI may reject registrations from terrestrial MSs on air cells. 

An air MS should not use a terrestrial cell, unless the aircraft is on or close to the ground. 

An MS supporting AGA service with range extension may also register as a terrestrial service only MS i.e. without 
AGA service subscriber class, but should not try to use air cells in that case. 

Clause 0.3 summarizes system requirements for Air - Ground - Air services. 

Clauses 0.4 to 0.7 define how the system requirements are implemented for AGA services. 
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0.3 System requirements regarding AGA 

Table 0. 1 describes what the various elements need to do in order to have a working AGA solution. 

Table 0.1 : AGA solution system requirements 



Solution Air MS Terrestrial lUIS Air BS Terrestrial BS 


Target: keep terrestrial MS away from air cell and move interfering air MS to air cell ASAP 


Allocation of subscriber 
class (off-line or over 
the air) 


Yes 


Yes 


Yes, if over the air is 
used 


Yes, if over the air is 
used 


Subscriber class 
aspects in roaming 


Prefer air cells based 
on highly preferred 
subscriber class 


Stay out of air 
cells 


Subscriber class 
broadcast with highly 
preferred subscriber 
class 


Subscriber class 
broadcast without highly 
preferred subscriber 
class 


Air cell preference 


Shall register as soon 
as an air cell becomes 
radio usable 








Neighbour cells 


Continuous monitoring 
of neighbour cells 


- 


Broadcast up to 31 
neighbours 


Broadcast of neighbour 
air cells 


Registration rejection 


Remember LA rejection 


Remember LA 
rejection 


Should reject terrestrial 
MS 


- 


Target: air MS shall not drag beyond maximum cell size 


Path delay 
measurement 


Distance reporting and 
response to polling; 
only one may be used 
by each BS 




Distance reporting or 
polling 




Path delay 


Cell reselection on 
maximum path delay 
exceeded 




Path delay 
measurement and 
notification to MS 




Target: extend cell size to 83 km 


A longer guard time 
between bursts 


Reduce ramp-up and 
ramp-down times 




Look for training 
sequence 

corresponding to the 
longer delay 





0.4 Signalling protocol 
0.4.1 General 

Clauses 0.4.2 to 0.4.7 describe mechanisms that are used to support AGA. 

0.4.2 Distance reporting 

The SwMI shall implement one of the following methods of distance reporting (distance reporting or polling) to detect 
if the path delay of the air MS exceeds the allowable path delay. 

The SwMI may order the MS to send some information during a distance reporting interval. In this case if the MS has 
nothing else to send the Null PDU shall be sent, see clause 16.4.11. SwMI may calculate the path delay and hence the 
distance of the MS from the serving base station. 

The SwMI may use a variant of D-MM STATUS to start the MS's distance reporting timer, refer to clause 16.10.48. 
The air MS shall support the D-MM STATUS PDU for distance reporting. The D-MM STATUS may be sent any time, 
but typically it is sent immediately after the MS has registered on the air cell. While the MS is starting transmission for 
any reason it shall stop the reporting timer and upon ceasing the transmission MS shall start the reporting timer. Upon 
expiry of the reporting timer the MS shall send a Null PDU unless the MS has something else to send. 
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MS A 




SwMI 


















Successful registration to the air cell 










D-MM STATUS (D-DISTANCE REPORTING REQUEST) 








Distance reporting timer 
Distance reporting validity 





Figure 0.1 : Starting distance reporting 

NOTE: Location Information Protocol may be also used to initiate periodic reporting, refer to 
TS 100 392-18-1 [19]. 

Alternatively, the SwMI may grant a slot (i.e. poll the MS) in order to make the MS transmit BL-DATA with an SDU 
(if ready) or a NULL PDU. 

The related transmissions from the MS shall be used on traffic channels as well as control channels (MCCH/SCCH and 
PDCH). This appHes also to the polHng of MSs by the SwMI. 



0.4.3 Excessive path delay 



The SwMI (base station) shall measure all transmissions from the air MS in air cells. If the path delay exceeds the limit 
set in the SwMI, the SwMI shall order the air MS to perform cell re-selection to another cell. This is done by including 
the power control element with value "maximum path delay exceeded" into any PDU addressed to the MS, see 
figure O.2. If the SwMI has nothing to send to the MS, it may send an empty MAC-RESOURCE PDU (without a 
TM-SDU). 

SwMI may also indicate when the path delay is almost exceeded using the same mechanism as for the maximum path 
delay exceeded with the power control element value "Maximum path delay almost exceeded". The actual path delay 
that invokes the sending information of the maximum path delay almost exceeded is outside the scope of the present 
document. 



MSA 



Any UL message, where maximum path delay 
is exceeded 



MAC-RESOURCE 



Power control element= max.path delay 
exceeded 



SwMl 



Figure 0.2: IVIaximum path delay has been exceeded 
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0.4.4 Cell re-selection 

An air MS shall be able to differentiate between air and terrestrial cells. 

Air cell is identified using the generic subscriber class mechanisms- by the fact that it broadcasts support of the highly 
preferred subscriber class reserved for AGA operation. An air MS prefers this cell over a terrestrial cell due to the fact 
that it is a highly preferred subscriber class cell. 

NOTE: Another solution is to store air cell identities into the air MS at subscription (preferred location area). Use 
of the highly preferred subscriber class mechanism for air cell preference is the recommended solution as 
it provides an easier global service access. 

Terrestrial cell is identified as any cell that is not an air cell. 

The air MS may be allowed to use terrestrial cells of the network, when the air cell coverage is missing (e.g. on the 
ground). If the MS stays registered to a terrestrial cell while it is high above ground, this could produce interference at 
distant terrestrial base stations on the same frequency. To avoid interference the air MS shall select the air cell as soon 
as it becomes radio usable, provided that the air cell supports the required services. See clause 0.4.7 for preferred 
subscriber classes and cell re-selection. 

A terrestrial MS should normally only use the air cells if it cannot find another cell that supports its subscriber class and 
is making an emergency call, refer to clause 14.5.7, for mobility purposes MS is allowed to a limited set of actions refer 
to clause 16.4.9. 

If terrestrial MSs are not allowed to use air cells then they shall not have a matching subscriber class profile. In that case 
SwMI shall apply subscriber class procedures, refer to clause 16.4.9 to prevent terrestrial MSs to use air cells. 

The SwMI should reject registrations from terrestrial MSs on air cells with reject cause "LA not allowed (LA 
rejection)". The terrestrial MS shall remember that it was rejected from the (air) cell, so that it shall not try to register on 
the cell again, even if the cell is ranked highest in the ranking list in terms of RSSI. Refer to clause O.7. 1 .3. 



0.4.5 Neighbour cells 



If air MSs are also to be allowed to use terrestrial cells, information for neighbouring terrestrial cells shall be included 
in the D-NWRK-BROADCAST PDU broadcast on air cells. The maximum number of neighbouring cells shall be 
supported by the air MSs and the air cells. The terrestrial BSs close to expected landing sites should broadcast air cell 
neighbour information so that the air MSs could go to the air cell as soon as possible, refer to table O.l. 

The neighbour cell information shall include the subscriber class element unless the neighbour and the serving cell 
support an identical set of subscriber classes, refer to clause 18.5.17 note 2 in the table in that clause. 

When an air MS is camped on a terrestrial cell, it shall perform constant monitoring of neighbouring cells, regardless of 
the serving cell's RSSI, with the intention of moving to an air cell as soon as the air cell becomes usable. 

0.4.6 Base station fallback 

The air MS shall favour a normal mode terrestrial base station over an air cell in fallback, if no other air cell is radio 
usable. 

NOTE: This requirement is in contradiction with the recommendation in TR 102 021-8, clause 4.7. The 

possibilities to communicate were deemed more important than possible interference prevention. In most 
cases an air MS user may be the only one using an air cell and base station fallback is not operationally 
viable. Therefore base station fallback should not to be used for air cells. 

0.4.7 Subscriber class 

The SwMI may assign a new subscriber class to an MS at any registration. The new subscriber class shall be effective 
immediately until a) the MS is assigned a new one, b) the MS is powered down or c) the MS migrates to another 
network, refer to clauses 16.4.9 and O.6. 

Clause 0.8 gives a guideline for subscriber class allocation in a network with air cells. 
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0.5 Range extension 
0.5.1 Background 

The air interface bursts are defined in figure 9.3 in clause 9.4.4.1. The figure 9.3 copied as figure 0.3 presents the 
TDMA frame and bursts. The related RF output power time mask is shown in the figure 6.3 in clause 6.4.5 and is 
copied as figure 0.4 for easier reference. 
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Figure 0.3: TETRA uplink bursts for n/4-DQPSK 
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Figure 0.4: TETRA RF output power time mask 

In the figure 0.4 times tj, t2 and t3 are defined as in the table 6.8 of clause 6.4.5. Table 0.2 presents the resulting delay 
tolerance when the useful part of an uplink burst (i.e. the period t2), transmitted on the timeslot TN = n by a far MS is 
not interfered by the ramp up (period tj) of an uplink burst from a near MS. 

Table 0.2: Ramp-up and ramp-down times for terrestrial services in modulation symbol periods 



Burst Type 


ti 


t2 


t3 


Total time 


Delay tolerance 


Control uplink 


16 


103 


15 


134 


7,5 


Normal uplink 


16 


231 


15 


262 


7 


Linearization burst, see note 


119 





15 


134 


7,5 


NOTE: By that definition of ti the timing of the linearization burst is referencing to the symbol time of SNmax 
instead of symbol time of SNO. 



NOTE 1: Although the tj and t3 values in the table 0.2 are given as number of symbols periods the nature of ramp- 
up and ramp-down time does not require an alignment to a number of symbol periods. 

NOTE 2: The ti and t3 values in the table 0.2 are maximum times and an implementation may use any shorter 
values as long as the adjacent channel requirements are fulfilled. 

The delay tolerance values in the table 0.2 are calculated with equation 0. 1 : 

Delay tolerance = Timeslot length - (Information length + Ramp-up time + Filter implementation) (0. 1) 
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where: 



EXAMPLE: As the length of the normal burst is 255 symbols and there are 231 symbols needed for the 
information transmission and ramp-up time is 16 symbols and one additional symbol time is 
allocated for the receiver filter implementation, then the delay tolerance for the normal uplink 

burst is: 

Delay tolerancejgj^gj,jj.j^j = T^ = 7 symbols (0.2) 

The corresponding maximum cell radius of a TETRA terrestrial cell is: 

Rxe^estriaLmax = 0,5 X T^ X T, X C = 58 km (0.3) 

Tj = 7 = number of symbols of delay tolerance. 
Tg = symbol period = 55,6 |is. 

c = electromagnetic wave propagation speed = 300 000 km/s. 

In practice, the useful part of an uplink burst (i.e. the period t2), transmitted on slot TN = n by a far MS at 58 km from 
the BS, is not interfered by the ramp up (period ti) of an uplink burst from a near MS, where the uplink burst from the 
near MS is transmitted on slot TN = (n + 1) (i.e. an MS at zero propagation time from the BS). 

This scenario (with reference to BS receiver input) is described in the figure O.5. The time is calculated in symbol 
periods in the figure O.5. The figure 0.5 also contains the applied solution as defined in clause O.5.2. 
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27 



248 255 258 



272 









Sloti 








Slot 2 




17 


231 
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^ 
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^^16 


231 




1 
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■^ 
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256 
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^ 


Air MS close to BS 




^ 


16 






8 


24 
/M3 


Air MS 83 km to BS 






270 
13\ 






231 






14 










//l3 






231 


13\ 











Figure 0.5: TETRA maximum round-trip delay 

If the round-trip delay of the far MS exceeds 7 symbols, then the near MS ramp up interferes with the last useful 
symbols of the far MS. 

In addition to the information carrying bursts the linearization burst as defined in clause 6.4.5 may cause interference, if 
it uses the whole allowed time in the time-mask. 
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0.5.2 Extended range requirements 



The range extension is implemented by shortening ramp-up and ramp-down times in the guard period between uplink 
bursts. The same adjacent channel requirements are applied as for terrestrial TETRA MSs, refer to clause 6.4, especially 
clauses 6.4.2.2.2 and 6.4.2.4. The air MS shall use shortened ti and t3 values as defined in table O.3. The information 
part of the burst shall be in the same location as in the terrestrial service. 

Table 0.3: Ramp-up and ramp-down times for AGA services in modulation symbol periods 



Burst Type 


ti 


t2 


t3 


Total time 


Delay tolerance 


Control uplink 


13 


103 


13 


125 


10.5 


Normal uplink 


13 


231 


13 


255 


10 


Linearization burst, see note 


116 





13 


128 


10.5 


NOTE: By that definition of ti the timing of the linearization burst is referencing to the symbol time of SNmax 
instead of symbol time of SNO. 



NOTE 1: Although the tj and t3 values in the table 0.3 are given as number of symbol periods the ramp-up and 
ramp-down times need not be exact number of symbol periods. 

EXAMPLE: Using ti value in table 0.3 for the normal uplink burst and other values as in equation 0.2 the air 

MS delay tolerance is: 

Delay tolerance^Q^ = T^j = 10 symbols (0.4) 

The corresponding maximum cell radius of a TETRA air cell using equation 0.2 is: 

RAGA.max = 0-5 X T^ X T, X c = 83 km (0.5) 

NOTE 2: Terrestrial MS using an air cell may reduce the maximum cell radius due to its longer ramp-up time 

especially, when it is close to the BS. Network operators should consider whether they allow terrestrial 
MSs to use air cells. 

BS can control the actual maximum range using the power control information element value "Maximum path delay 
exceeded" as defined in clause 23.7.3.2. 



0.6 Subscriber class procedures 
0.6.1 Purpose of the subscriber class 

AGA service requires that SwMI applies subscriber class procedures to prevent terrestrial MSs to use air cells, refer to 
clauses 14.5.7, 0.4.7 and O.7.I.2. 

The SwMI may include the subscriber class element in all cases of location update signalling. If the SwMI sends the 
optional subscriber class element then the MS shall use the new subscriber class profile as defined in clause 16.4.9. 

0.6.2 Preferred subscriber classes 

The values for the subscriber class information elements in amended clauses 16.10.49 and 18.5.22 to support AGA 
service and to allow a more flexible control of cell re-selection in some other cases are defined in clauses O.7. 1 .2 and 
O.7.I.3. 

The subscriber class element shall be broadcasted by the SwMI to indicate which subscriber classes are supported on 
the cell as defined in the table O.5. The first two subscriber classes are the highly preferred subscriber classes and the 
next two are the preferred subscriber classes. Refer to clause 0.8 how those are used for the AGA service. 
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0.7 Amendments and modifications due to the AGA 
service 

0.7.1 Modified information elements 
0.7.1.1 General 

In order to support protocol defined in clauses 0.4 to 0.6 some of the air interface protocol PDU information elements 
shall be modified as presented in clauses 0.7.1.2 to O.7.I.4. 

0.7.1 .2 Amendment to clause 1 6.1 0.49 Subscriber class 

The subscriber class information element shall subdivide the MS population in up to 16 classes (see definition) 
represented as a bit map as defined in table O.4. 

Table 0.4: Subscriber class information element 



Information element 


Length 


Value 


Remark 


Class 1 







Not a member of highly preferred cell subscriber class 1 


1 


Member of highly preferred cell subscriber class 1 


Class 2 







Not a member of highly preferred cell subscriber class 2 


1 


Member of highly preferred cell subscriber class 2 


Class 3 







Not a member of preferred cell subscriber class 3 


1 


Member of preferred cell subscriber class 3 


Class 4 







Not a member of preferred cell subscriber class 4 


1 


Member of preferred cell subscriber class 4 


Class 5 







Not a member of subscriber class 5 


1 


Member of subscriber class 5 


etc. 







Not a member of subscriber class n 


1 


Member of subscriber class n 


Class 16 







Not a member of subscriber class 16 


1 


Member of subscriber class 16 



0.7. 1 .3 Amendment to clause 1 8.5.22 Subscriber class 

The subscriber class information element shall be used by the SwMl to indicate which subscriber classes are allowed to 
use this cell as defined in table O.5. 

Table 0.5: Subscriber class information element 



Information element 


Length 


Value 


Remark 


Class 1 







Subscriber class not supported on cell 


1 


Highly preferred cell for subscriber class 


Class 2 







Subscriber class not supported on cell 


1 


Highly preferred cell for subscriber class 


Class 3 







Subscriber class not supported on cell 


1 


Preferred cell for subscriber class 


Class 4 







Subscriber class not supported on cell 


1 


Preferred cell for subscriber class 


Class 5 







Subscriber class not supported on cell 


1 


Subscriber class supported on cell 


etc. 







Subscriber class not supported on cell 


1 


Subscriber class supported on cell 


Class 16 







Subscriber class not supported on cell 


1 


Subscriber class supported on cell 
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0.7.1 .4 Modification of clause 21 .5.3 Power control 

For the BSs supporting AGA service the power control information element shall be modified as presented in the 
table O.6. 

Table 0.6: Power control information element contents 



Information element 


Length 


Type 


Value 


Remark 


Power control 


4 


M 


OOOO2 


No change in power 


0001 2 


Increase power by 1 step 


001 O2 


Increase power by 2 steps 


0011 2 


Increase power by 3 steps 


01002 


Increase power by 4 steps 


01012 


Increase power by 5 steps 


01102 


Increase power by 6 steps or maximum path delay 
almost exceeded, see note 


01112 


IVIaximum path delay exceeded 


10002 


Revert to open loop power control 


1001 2 


Decrease power by 1 step 


10102 


Decrease power by 2 steps 


10112 


Decrease power by 3 steps 


11002 


Decrease power by 4 steps 


11012 


Decrease power by 5 steps 


11102 


Decrease power by 6 steps 


11112 


Radio uplink failure 


NOTE: The value "maximum path delay almost exceeded" is applicable to the AGA service and shall not 
generate a further increase of the transmitted power of the air MS. 



0.7.2 Modified protocols 
0.7.2.1 General 

In order to support AGA service protocol defined in clauses 0.4 to 0.6 the air interface protocol shall be modified as 
defined in clauses 0.7.2.2 to 0. 7.2.4. 

0.7.2.2 Monitoring modification of clauses 18.3.4.2 and 18.3.4.5.1 

While attached to a terrestrial cell the air MS shall monitor neighbour cells continuously and the MLE shall not issue a 
TL-MONITOR-LIST request parameter with an empty list of neighbour cell channels as parameter. Refer to 
clause O.4.4. 

While attached to an air cell the air MS may monitor neighbour cells continuously in order to better support all 
requirements in clause O.7.2.3. 

0.7.2.3 MS cell selection modification of clause 18.3.4.5.7 

In order to force air MS to use air cells also at low altitudes the air MS cell selection protocol as defined in 
clause 18.3.4.5.7 shall be modified as presented in the following paragraphs of the present clause. 

If the air MS supports highly preferred bits, the highly preferred cell (i.e. where the cell broadcast and the subscriber 
class profile have a match in this bit position) shall be selected as soon as it becomes: 

• radio usable; 

• offers adequate service; and 
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• the current serving cell is not a highly preferred cell. 

Preferred cells are used for subscriber based cell precedence (priority cell in "BS service details" element of SYSINFO 
broadcast affects all MSs). Preferred cell affects only those MSs that have a matching subscriber class profile, the MS 
shall combine the match with other services to order the cells in the ranking list. 

The criteria in clause 18.3.4.5.7 "Criteria for initiating the cell re-selection procedures" shall be appended with the 
following conditions that shall cause the air MS to rate a neighbour cell to have better service than the current serving 
cell: 

• The neighbour cell is a highly preferred cell for the MS's subscriber class but the serving cell is not. This 
condition shall also override the postponement of cell re-selection due to ongoing circuit mode call; and 

• The neighbour cell is a preferred cell for the MS's subscriber class but the serving cell is not a highly preferred 
or preferred cell. 

In addition to those ranking reasons air MS may use the criteria defined in clause 18.3.4.5.7: 

• the MS subscriber class is supported on the neighbour cell but not on the serving cell; 

• the neighbour cell supports system-wide services which are not supported by the serving cell; 

• the neighbour cell is a priority cell and the serving cell is not a priority cell; 

• the neighbour cell supports a service (i.e. TETRA standard speech, circuit mode data or TETRA packet data 
services) which is not supported by the serving cell and the air MS requires that service to be available; 

• the neighbour cell supports air interface encryption which is not supported by the serving cell and the air MS 
requires that air interface encryption is available; 

• the cell service level indicates that the neighbour cell is more lightly loaded (TCH and PDCH load) than the 
serving cell; and 

• the neighbour cell is a preferred cell (or "home cell") or belongs to a preferred LA. 

The MS supporting AGA service should choose to initiate cell re-selection as soon as the neighbour cell becomes radio 
usable as defined in clause 18.3.4.5.6. If there is more than one neighbour cell which is radio usable, the air MS should 
choose the one which has the highest ranking in the ranking list and which best satisfies the service requirements for the 
air MS. 

0.7.2.4 Modification of clause 23.4.4.3 

The air MS closed loop power control shall be modified on the Power control information element so that air MSs shall 
interpret the information element value "Increase power by 6 steps or maximum path delay almost exceeded" as 
"Maximum path delay almost exceeded" and upon reception of that value should start cell re-selection and not to 
increase output power, refer to clause O.4.3. 
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0.8 Example of subscriber class values used by 
operators and users in some networks 

In order to promote interoperability, some values of subscriber class are defined and used by operators, users and 
manufacturers and presented in the table O.7. This definition facilitates inter-operability and support very wide-area 
roaming and migration of air MSs, subject to operator and user subscription agreement. 

Table 0.7: Subscriber class information element values for AGA service 



Information element 


Length 


Value 


Remark 


Class 1 




any 


Not defined by the present annex 


Class 2 




1 


Highly preferred cell for subscriber class 


Class 3 




any 


Not defined by the present annex 


Class 4 




any 


Not defined by the present annex 


Class 5 




any 


Not defined by the present annex 


Class 6 




any 


Not defined by the present annex 


Class 7 




any 


Not defined by the present annex 


Class 8 




any 


Not defined by the present annex 


Class 9 




any 


Not defined by the present annex 


Classic 




any 


Not defined by the present annex 


Class 1 1 




any 


Not defined by the present annex 


Class 12 




any 


Not defined by the present annex 


Class 12 




any 


Not defined by the present annex 


Class 14 




any 


Not defined by the present annex 


Class 15 




any 


Not defined by the present annex 


Class 16 




any 


Not defined by the present annex 



0.9 Requirements for air MSs 



On transmitter characteristics air MSs shall conform to requirements in clause 6.4 with additional requirements as 
defined in clause O.5.2. 

On signalling protocol air MSs shall behave as defined in clauses 0.4, 0.6 and O.7.2. 

Air MSs shall utilize amended information elements as defined in clause 0.7.1. 



0.1 Requirements for AGA BSs 

Based on specifications in clause 0.5.2 the maximum allowable path delay is 10,5 symbols. The air BS receiver shall 
apply at least that large synchronization search window in order to receive bursts from near-by and distant air MSs. 

NOTE: The air MSs use a shorter ramp-up period than the one normally used for terrestrial services and that may 
affect to the design of the AGC mechanism of BSs. 

AGA BSs should use signalling protocol as defined in clauses 0.4, 0.6 and O.7.2. 

AGA BS shall use in the signalling protocol information elements as defined in clause 0.7.1. 

In order to reduce interferences from air MSs the BS may use closed loop power control and/or use a suitable low value 
for the MS TXPWR MAX CELL in the SYSINFO PDU broadcast, refer to clause 23.4.4.2. 
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Annex P (normative): 

QAM modulation symbol allocations and symbol set 

definitions 

P.1 QAM modulation symbol sub-carrier allocation 

Clause 9.4.8.2 describes the sub-carrier symbol sets. Clauses P. 1.1 to P. 1.6 define how symbol sets are allocated within 
bursts. 



P.1 .1 Control uplink Burst (CB) 

The allocation of the sub-carrier symbols in the CB shall be in accordance with tables P. 1 to P.4. 

Table P.1 : Allocation of sub-carrier symbols in CB for 8 sub-carriers (25 kHz) case 





1 

2 
3 
4 
5 
6 
7 
tj 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


S1 


S9 


D1 


D7 


D15 


P1 


D25 


D33 


D41 


P5 


D51 


D59 


D67 


P9 


S2 


S10 


H1 


D8 


D16 


H3 


D26 


D34 


D42 


H5 


D52 


D60 


D68 


H7 


S3 


S11 


D2 


D9 


D17 


P2 


D27 


D35 


D43 


P6 


D53 


D61 


D69 


P10 


S4 


S12 


D3 


D10 


D18 


D23 


D28 


D36 


D44 


D49 


D54 


D62 


D70 


D75 


S5 


S13 


D4 


D11 


D19 


D24 


D29 


D37 


D45 


D50 


D55 


D63 


D71 


D76 


S6 


S14 


D5 


D12 


D20 


P3 


D30 


D38 


D46 


P7 


D56 


D64 


D72 


P11 


S7 


S15 


H2 


D13 


D21 


H4 


D31 


D39 


D47 


H6 


D57 


D65 


D73 


H8 


S8 


S16 


D6 


D14 


D22 


P4 


D32 


D40 


D48 


P8 


D58 


D66 


D74 


P12 



Table P.2: Allocation of sub-carrier symbols in CB for 16 sub-carriers (50 kHz) case 





1 

2 
3 

4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
tJ 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


SI 


S17 


D1 


D15 


D31 


PI 


D53 


D69 


D85 


P9 


D107 


D123 


D139 


P17 


S2 


S18 


D2 


D16 


D32 


D47 


D54 


D70 


D86 


D101 


D108 


D124 


D140 


D155 


S3 


S19 


D3 


D17 


D33 


P2 


D55 


D71 


D87 


P10 


D109 


D125 


D141 


P18 


S4 


S20 


D4 


D18 


D34 


D48 


D56 


D72 


D88 


D102 


D110 


D126 


D142 


D156 


S5 


S21 


D5 


D19 


D35 


P3 


D57 


D73 


D89 


P11 


D111 


D127 


D143 


P19 


S6 


S22 


H1 


D20 


D36 


H3 


D58 


D74 


D90 


H5 


D112 


D128 


D144 


H7 


S7 


S23 


D6 


D21 


D37 


P4 


D59 


D75 


D91 


P12 


D113 


D129 


D145 


P20 


S8 


S24 


D7 


D22 


D38 


D49 


D60 


D76 


D92 


D103 


D114 


D130 


D146 


D157 


S9 


S25 


D8 


D23 


D39 


D50 


D61 


D77 


D93 


D104 


D115 


D131 


D147 


D158 


S10 


S26 


D9 


D24 


D40 


P5 


D62 


D78 


D94 


P13 


D116 


D132 


D148 


P21 


S11 


S27 


H2 


D25 


D41 


H4 


D63 


D79 


D95 


H6 


D117 


D133 


D149 


H8 


S12 


S28 


D10 


D26 


D42 


P6 


D64 


D80 


D96 


P14 


D118 


D134 


D150 


P22 


S13 


S29 


D11 


D27 


D43 


D51 


D65 


D81 


D97 


D105 


D119 


D135 


D151 


D159 


S14 


S30 


D12 


D28 


D44 


P7 


D66 


D82 


D98 


P15 


D120 


D136 


D152 


P23 


S15 


S31 


D13 


D29 


D45 


D52 


D67 


D83 


D99 


D106 


D121 


D137 


D153 


D160 


S16 


S32 


D14 


D30 


D46 


P8 


D68 


D84 


D100 


P16 


D122 


D138 


D154 


P24 
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Table P.3: Allocation of sub-carrier symbols in CB for 32 sub-carriers (100 kHz) case 



10 11 12 13 



14 





1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

Tj 



SI 


S33 


D1 


D31 


D63 


P1 


D109 


D141 


D173 


P17 


D219 


D251 


D283 


P33 


S2 


S34 


D2 


D32 


D64 


D95 


D110 


D142 


D174 


D205 


D220 


D252 


D284 


D315 


S3 


S35 


D3 


D33 


D65 


P2 


Dill 


D143 


D175 


P18 


D221 


D253 


D285 


P34 


S4 


S36 


D4 


D34 


D66 


D96 


D112 


D144 


D176 


D206 


D??? 


D254 


D286 


D316 


S5 


S37 


D5 


D35 


D67 


P3 


D113 


D145 


D177 


P19 


D223 


D255 


D287 


P35 


S6 


S38 


D6 


D36 


D68 


D97 


D114 


D146 


D178 


D207 


D224 


D256 


D288 


D317 


S7 


S39 


D7 


D37 


D69 


P4 


D115 


D147 


D179 


P20 


D225 


D257 


D289 


P36 


S8 


S40 


D8 


D38 


D70 


D98 


D116 


D148 


D180 


D208 


D226 


D258 


D290 


D318 


S9 


S41 


D9 


D39 


D71 


P5 


D117 


D149 


D181 


P21 


D227 


D259 


D291 


P37 


S10 


S42 


D10 


D40 


D72 


D99 


D118 


D150 


D182 


D209 


D228 


D260 


D292 


D319 


S11 


S43 


D11 


D41 


D73 


P6 


D119 


D151 


D183 


P22 


D229 


D261 


D293 


P38 


S12 


S44 


D12 


D42 


D74 


D100 


D120 


D152 


D184 


D210 


D230 


D262 


D294 


D320 


S13 


S45 


D13 


D43 


D75 


P7 


D121 


D153 


D185 


P23 


D231 


D263 


D295 


P39 


S14 


S46 


H1 


D44 


D76 


H3 


D122 


D154 


D186 


H5 


D232 


D264 


D296 


H7 


S15 


S47 


D14 


D45 


D77 


P8 


D123 


D155 


D187 


P24 


D233 


D265 


D297 


P40 


S16 


S48 


D15 


D46 


D78 


D101 


D124 


D156 


D188 


D211 


D234 


D266 


D298 


D321 


S17 


S49 


D16 


D47 


D79 


D102 


D125 


D157 


D189 


D212 


D235 


D267 


D299 


D322 


S18 


S50 


D17 


D48 


D80 


P9 


D126 


D158 


D190 


P25 


D236 


D268 


D300 


P41 


S19 


S51 


H2 


D49 


D81 


H4 


D127 


D159 


D191 


H6 


D237 


D269 


D301 


H8 


S20 


S52 


D18 


D50 


D82 


P10 


D128 


D160 


D192 


P26 


D238 


D270 


D302 


P42 


S21 


S53 


D19 


D51 


D83 


D103 


D129 


D161 


D193 


D213 


D239 


D271 


D303 


D323 


S22 


S54 


D20 


D52 


D84 


P11 


D130 


D162 


D194 


P27 


D240 


D272 


D304 


P43 


S23 


S55 


D21 


D53 


D85 


D104 


D131 


D163 


D195 


D214 


D241 


D273 


D305 


D324 


S24 


S56 


D22 


D54 


D86 


P12 


D132 


D164 


D196 


P28 


D242 


D274 


D306 


P44 


S25 


S57 


D23 


D55 


D87 


D105 


D133 


D165 


D197 


D215 


D243 


D275 


D307 


D325 


S26 


S58 


D24 


D56 


D88 


P13 


D134 


D166 


D198 


P29 


D244 


D276 


D308 


P45 


S27 


S59 


D25 


D57 


D89 


D106 


D135 


D167 


D199 


D216 


D245 


D277 


D309 


D326 


S28 


S60 


D26 


D58 


D90 


P14 


D136 


D168 


D200 


P30 


D246 


D278 


D310 


P46 


S29 


S61 


D27 


D59 


D91 


D107 


D137 


D169 


D201 


D217 


D247 


D279 


D311 


D327 


S30 


S62 


D28 


D60 


D92 


P15 


D138 


D170 


D202 


P31 


D248 


D280 


D312 


P47 


S31 


S63 


D29 


D61 


D93 


D108 


D139 


D171 


D203 


D218 


D249 


D281 


D313 


D328 


S32 


S64 


D30 


D62 


D94 


P16 


D140 


D172 


D204 


P32 


D250 


D282 


D314 


P48 
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Table P.4: Allocation of sub-carrier symbols in CB 48 sub-carriers (150 kHz) case 





1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
tj 



1 


2 


3 


4 


5 


6 


7 


8 


9 


1G 


11 


12 


13 


14 


SI 


S49 


D1 


D47 


D95 


PI 


D165 


D213 


D261 


P25 


D331 


D379 


D427 


P49 


S2 


S50 


D2 


D48 


D96 


D143 


Dies 


D214 


D262 


D3G9 


D332 


D380 


D428 


D475 


S3 


S51 


D3 


D49 


D97 


P2 


D167 


D215 


D263 


P26 


D333 


D381 


D429 


P5G 


S4 


S52 


D4 


D50 


D98 


D144 


D168 


D216 


D264 


D31G 


D334 


D382 


D43G 


D476 


S5 


S53 


D5 


D51 


D99 


P3 


D169 


D217 


D265 


P27 


D335 


D383 


D431 


P51 


S6 


S54 


D6 


D52 


D100 


D145 


D17G 


D218 


D266 


D311 


D336 


D384 


D432 


D477 


S7 


S55 


D7 


D53 


Did 


P4 


D171 


D219 


D267 


P28 


D337 


D385 


D433 


P52 


S8 


S56 


D8 


D54 


D102 


D146 


D172 


D220 


D268 


D312 


D338 


D386 


D434 


D478 


S9 


S57 


D9 


D55 


D103 


P5 


D173 


D221 


D269 


P29 


D339 


D387 


D435 


P53 


S10 


S58 


DIG 


D56 


D104 


D147 


D174 


D222 


D27G 


D313 


D340 


D388 


D436 


D479 


S11 


S59 


D11 


D57 


D105 


P6 


D175 


D223 


D271 


P30 


D341 


D389 


D437 


P54 


S12 


S60 


D12 


D58 


D106 


D148 


D176 


D224 


D272 


D314 


D342 


D390 


D438 


D480 


S13 


S61 


D13 


D59 


D107 


P7 


D177 


D225 


D273 


P31 


D343 


D391 


D439 


P55 


S14 


S62 


D14 


D60 


D108 


D149 


D178 


D226 


D274 


D315 


D344 


D392 


D44G 


D481 


S15 


S63 


D15 


D61 


D109 


P8 


D179 


D227 


D275 


P32 


D345 


D393 


D441 


P56 


S16 


S64 


DIG 


D62 


DUG 


D15G 


D18G 


D228 


D276 


D316 


D346 


D394 


D442 


D482 


S17 


S65 


D17 


D63 


Dill 


P9 


D181 


D229 


D277 


P33 


D347 


D395 


D443 


P57 


S18 


S66 


D18 


D64 


D112 


D151 


D182 


D230 


D278 


D317 


D348 


D396 


D444 


D483 


S19 


S67 


D19 


D65 


D113 


P10 


D183 


D231 


D279 


P34 


D349 


D397 


D445 


P58 


S20 


S68 


D20 


D66 


D114 


D152 


D184 


D232 


D28G 


D318 


D350 


D398 


D446 


D484 


S21 


S69 


D21 


D67 


D115 


P11 


D185 


D233 


D281 


P35 


D351 


D399 


D447 


P59 


S22 


S70 


HI 


D68 


D116 


H3 


D186 


D234 


D282 


H5 


D352 


D400 


D448 


H7 


S23 


S71 


D22 


D69 


D117 


P12 


D187 


D235 


D283 


P36 


D353 


D401 


D449 


P6G 


S24 


S72 


D23 


D70 


D118 


D153 


D188 


D236 


D284 


D319 


D354 


D402 


D45G 


D485 


S25 


S73 


D24 


D71 


D119 


D154 


D189 


D237 


D285 


D32G 


D355 


D403 


D451 


D486 


S26 


S74 


D25 


D72 


D12G 


P13 


D19G 


D238 


D286 


P37 


D356 


D404 


D452 


P61 


S27 


S75 


H2 


D73 


D121 


H4 


D191 


D239 


D287 


H6 


D357 


D405 


D453 


H8 


S28 


S76 


D26 


D74 


D122 


P14 


D192 


D240 


D288 


P38 


D358 


D406 


D454 


P62 


S29 


S77 


D27 


D75 


D123 


D155 


D193 


D241 


D289 


D321 


D359 


D407 


D455 


D487 


S30 


S78 


D28 


D76 


D124 


P15 


D194 


D242 


D29G 


P39 


D360 


D408 


D456 


P63 


S31 


S79 


D29 


D77 


D125 


D156 


D195 


D243 


D291 


D322 


D361 


D409 


D457 


D488 


S32 


S80 


D30 


D78 


D126 


P16 


D196 


D244 


D292 


P40 


D362 


D410 


D458 


P64 


S33 


S81 


D31 


D79 


D127 


D157 


D197 


D245 


D293 


D323 


D363 


D411 


D459 


D489 


S34 


S82 


D32 


D80 


D128 


P17 


D198 


D246 


D294 


P41 


D364 


D412 


D46G 


P65 


S35 


S83 


D33 


D81 


D129 


D158 


D199 


D247 


D295 


D324 


D365 


D413 


D461 


D490 


S36 


S84 


D34 


D82 


D13G 


P18 


D2GG 


D248 


D296 


P42 


D366 


D414 


D462 


P66 


S37 


S85 


D35 


D83 


D131 


D159 


D2G1 


D249 


D297 


D325 


D367 


D415 


D463 


D491 


S38 


S86 


D36 


D84 


D132 


P19 


D2G2 


D250 


D298 


P43 


D368 


D416 


D464 


P67 


S39 


S87 


D37 


D85 


D133 


D16G 


D2G3 


D251 


D299 


D326 


D369 


D417 


D465 


D492 


S40 


S88 


D38 


D86 


D134 


P20 


D2G4 


D252 


D3GG 


P44 


D370 


D418 


D466 


P68 


S41 


S89 


D39 


D87 


D135 


D161 


D2G5 


D253 


D3G1 


D327 


D371 


D419 


D467 


D493 


S42 


S90 


D40 


D88 


D136 


P21 


D2G6 


D254 


D3G2 


P45 


D372 


D420 


D468 


P69 


S43 


S91 


D41 


D89 


D137 


D162 


D2G7 


D255 


D3G3 


D328 


D373 


D421 


D469 


D494 


S44 


S92 


D42 


D90 


D138 


P22 


D2G8 


D256 


D3G4 


P46 


D374 


D422 


D47G 


P7G 


S45 


S93 


D43 


D91 


D139 


D163 


D2G9 


D257 


D3G5 


D329 


D375 


D423 


D471 


D495 


S46 


S94 


D44 


D92 


D14G 


P23 


D21G 


D258 


D3G6 


P47 


D376 


D424 


D472 


P71 


S47 


S95 


D45 


D93 


D141 


D164 


D211 


D259 


D3G7 


D33G 


D377 


D425 


D473 


D496 


S48 


S96 


D46 


D94 


D142 


P24 


D212 


D260 


D3G8 


P48 


D378 


D426 


D474 


P72 
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The allocation of the sub-carrier symbols and their content are presented in table P.5. 

Table P.5: Control Uplink Burst (CB) for QAM 











BNmax 




Channel Bandwidth 


SSSet 
(see note) 


Number of 
SS symbols 


Set content 


4Q 


16Q 


64Q 


Definition 


All 


H1 to H8 


8 


Uplink slot header set 


16 


See clause 8 


25 kHz 


S1 toS16 


16 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 toP12 


12 


Half-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.4 


D1 to D76 


76 


Half-slot uplink data set 


152 


304 


456 


See clause 8 


50 kHz 


S1 to S32 


32 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 to P24 


24 


Half-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.4 


D1 to D160 


160 


Half-slot uplink data set 


320 640 960 


See clause 8 


100 kHz 


S1 to S64 


64 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 to P48 


48 


Half-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.4 


D1 to D328 


328 


Half-slot uplink data set 


656 1312 1968 


See clause 8 


150 KHz 


S1 to S96 


96 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 to P72 


72 


Half-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.4 


D1 to D496 


496 


Half-slot uplink data set 


9921 198412976 


See clause 8 


NOTE: SS is an abbreviation of sub-carrier symbol. 



P.1 .2 Random Access uplink Burst (RAB) 

The allocation of the sub-carrier symbols in the RAB shall be in accordance with table P. 6. 

Table P.6: Allocation of sub-carrier symbols in RAB 





1 

2 
3 

4 
5 
6 

7 
tj 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


SI 


S9 


D1 


D9 


D17 


PI 


D29 


D37 


D45 


P5 


D57 


D65 


D73 


P9 


S2 


S10 


D2 


D10 


D18 


D25 


D30 


D38 


D46 


D53 


D58 


D66 


D74 


D81 


S3 


S11 


D3 


D11 


D19 


P2 


D31 


D39 


D47 


P6 


D59 


D67 


D75 


P10 


S4 


S12 


D4 


D12 


D20 


D26 


D32 


D40 


D48 


D54 


D60 


D68 


D76 


D82 


S5 


S13 


D5 


D13 


D21 


D27 


D33 


D41 


D49 


D55 


D61 


D69 


D77 


D83 


S6 


S14 


D6 


D14 


D22 


P3 


D34 


D42 


D50 


P7 


D62 


D70 


D78 


P11 


S7 


S15 


D7 


D15 


D23 


D28 


D35 


D43 


D51 


D56 


D63 


D71 


D79 


D84 


S8 


S16 


D8 


D16 


D24 


P4 


D36 


D44 


D52 


P8 


D64 


D72 


D80 


P12 



The allocation of the sub-carrier symbols and their content are presented in table P.7. 

Table P.7: Random Access Uplink Burst (CB) 



SSSet 
(see note) 


Number of 
SS symbols 


Set content 


BNmax 


Definition 


S1 toS16 


16 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


PI to P12 


12 


Half-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.4 


D1 to D84 


84 


Random access data set 


168 


See clause 8 


NOTE: SS is an abbreviation of sub-carrier symbol. 



P.1 .3 Linearization uplink Burst (LB) 



The LB may be used by the MSs to linearize their transmitters. The LB contains no useful symbols and its timing shall 
only be determined by the time mask (see clause 6.4.10). 
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P.1 .4 Normal Uplink Burst (NUB) 



The allocation of the sub-carrier symbols in the NUB shall be in accordance with tables P. 8 to P.l 1. The NUB shall be 
used by MS to transmit control messages to the BS. 
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Table P.8: Allocation of sub-carrier symbols in NUB for 8 sub-carriers (25 kHz) case 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


30 


31 


SI 


S9 


D1 


D7 


D15 


D23 


PI 


D33 


D41 


D49 


D57 


P5 


D67 


D75 


D83 


D91 


P9 


D101 


D109 


D117 


D125 


P13 


D137 


D145 


D153 


D161 


P17 


D173 


D181 


D189 


P21 


S2 


S10 


H1 


D8 


D16 


D24 


H3 


D34 


D42 


D50 


D58 


H5 


D68 


D76 


D84 


D92 


H7 


D102 


D110 


D118 


D126 


D133 


D138 


D146 


D154 


D162 


D169 


D174 


D182 


D190 


D197 


S3 


S11 


D2 


D9 


D17 


D25 


P2 


D35 


D43 


D51 


D59 


P6 


D69 


D77 


D85 


D93 


P10 


D103 


D111 


D119 


D127 


P14 


D139 


D147 


D155 


D163 


P18 


D175 


D183 


D191 


P22 


S4 


S12 


D3 


D10 


D18 


D26 


D31 


D36 


D44 


D52 


D60 


D65 


D70 


D78 


D86 


D94 


D99 


D104 


D112 


D120 


D128 


D134 


D140 


D148 


D156 


D164 


D170 


D176 


D184 


D192 


D198 


S5 


S13 


D4 


D11 


D19 


D27 


D32 


D37 


D45 


D53 


D61 


D66 


D71 


D79 


D87 


D95 


D100 


D105 


D113 


D121 


D129 


D135 


D141 


D149 


D157 


D165 


D171 


D177 


D185 


D193 


D199 


S6 


S14 


D5 


D12 


D20 


D28 


P3 


D38 


D46 


D54 


D62 


P7 


D72 


D80 


D88 


D96 


P11 


D106 


D114 


D122 


D130 


P15 


D142 


D150 


D158 


D166 


P19 


D178 


D186 


D194 


P23 


S7 


S15 


H2 


D13 


D21 


D29 


H4 


D39 


D47 


D55 


D63 


H6 


D73 


D81 


D89 


D97 


H8 


D107 


D115 


D123 


D131 


D136 


D143 


D151 


D159 


D167 


D172 


D179 


D187 


D195 


D200 


S8 


S16 


D6 


D14 


D22 


D30 


P4 


D40 


D48 


D56 


D64 


P8 


D74 


D82 


D90 


D98 


P12 


D108 


D116 


D124 


D132 


P16 


D144 


D152 


D160 


D168 


P20 


D180 


D188 


D196 


P24 



Table P.9: Allocation of sub-carrier symbols in NUB for 16 sub-carriers (50 kHz) case 





1 

2 
3 

4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
tj 



10 11 12 13 14 15 16 17 1{ 



19 20 21 22 23 24 25 26 27 28 29 30 31 



81 


S17 


D1 


D15 


D31 


D47 


PI 


D69 


D85 


D101 


D117 


P9 


D139 


D155 


D171 


D187 


P17 


D209 


D225 


D241 


D257 


P25 


D281 


D297 


D313 


D329 


P33 


D353 


D369 


D385 


P41 


32 


S18 


D2 


D16 


D32 


D48 


D63 


D70 


D86 


D102 


D118 


D133 


D140 


D156 


D172 


D188 


D203 


D210 


D226 


D242 


D258 


D273 


D282 


D298 


D314 


D330 


D345 


D354 


D370 


D386 


D401 


S3 


S19 


D3 


D17 


D33 


D49 


P2 


D71 


D87 


D103 


D119 


P10 


D141 


D157 


D173 


D189 


P18 


D211 


D227 


D243 


D259 


P26 


D283 


D299 


D315 


D331 


P34 


D355 


D371 


D387 


P42 


S4 


S20 


D4 


D18 


D34 


D50 


D64 


D72 


D88 


D104 


D120 


D134 


D142 


D158 


D174 


D190 


D204 


D212 


D228 


D244 


D260 


D274 


D284 


D300 


D316 


D332 


D346 


D356 


D372 


D388 


D402 


S5 


S21 


D5 


D19 


D35 


D51 


P3 


D73 


D89 


D105 


D121 


P11 


D143 


D159 


D175 


D191 


P19 


D213 


D229 


D245 


D261 


P27 


D285 


D301 


D317 


D333 


P35 


D357 


D373 


D389 


P43 


S6 


S22 


H1 


D20 


D36 


D52 


H3 


D74 


D90 


D106 


D122 


H5 


D144 


D160 


D176 


D192 


H7 


D214 


D230 


D246 


D262 


D275 


D286 


D302 


D318 


D334 


D347 


D358 


D374 


D390 


D403 


S7 


S23 


D6 


D21 


D37 


D53 


P4 


D75 


D91 


D107 


D123 


P12 


D145 


D161 


D177 


D193 


P20 


D215 


D231 


D247 


D263 


P28 


D287 


D303 


D319 


D335 


P36 


D359 


D375 


D391 


P44 


SB 


S24 


D7 


D22 


D38 


D54 


D65 


D76 


D92 


D108 


D124 


D135 


D146 


D162 


D178 


D194 


D205 


D216 


D232 


D248 


D264 


D276 


D288 


D304 


D320 


D336 


D348 


D360 


D376 


D392 


D404 


S9 


S25 


D8 


D23 


D39 


D55 


D66 


D77 


D93 


D109 


D125 


D136 


D147 


D163 


D179 


D195 


D206 


D217 


D233 


D249 


D265 


D277 


D289 


D305 


D321 


D337 


D349 


D361 


D377 


D393 


D405 


S10 


S26 


D9 


D24 


D40 


D56 


P5 


D78 


D94 


D110 


D126 


P13 


D148 


D164 


D180 


D196 


P21 


D218 


D234 


D250 


D266 


P29 


D290 


D306 


D322 


D338 


P37 


D362 


D378 


D394 


P45 


S11 


S27 


H2 


D25 


D41 


D57 


H4 


D79 


D95 


D111 


D127 


H6 


D149 


D165 


D181 


D197 


H8 


D219 


D235 


D251 


D267 


D278 


D291 


D307 


D323 


D339 


D350 


D363 


D379 


D395 


D406 


S12 


S28 


D10 


D26 


D42 


D58 


P6 


D80 


D96 


D112 


D128 


P14 


D150 


D166 


D182 


D198 


P22 


D220 


D236 


D252 


D268 


P30 


D292 


D308 


D324 


D340 


P38 


D364 


D380 


D396 


P46 


S13 


S29 


D11 


D27 


D43 


D59 


D67 


D81 


D97 


D113 


D129 


D137 


D151 


D167 


D183 


D199 


D207 


D221 


D237 


D253 


D269 


D279 


D293 


D309 


D325 


D341 


D351 


D365 


D381 


D397 


D407 


S14 


S30 


D12 


D28 


D44 


D60 


P7 


D82 


D98 


D114 


D130 


P15 


D152 


D168 


D184 


D200 


P23 


D222 


D238 


D254 


D270 


P31 


D294 


D310 


D326 


D342 


P39 


D366 


D382 


D398 


P47 


S15 


S31 


D13 


D29 


D45 


D61 


D68 


D83 


D99 


D115 


D131 


D138 


D153 


D169 


D185 


D201 


D208 


D223 


D239 


D255 


D271 


D280 


D295 


D311 


D327 


D343 


D352 


D367 


D383 


D399 


D408 


S16 


S32 


D14 


D30 


D46 


D62 


P8 


D84 


D100 


D116 


D132 


P16 


D154 


D170 


D186 


D202 


P24 


D224 


D240 


D256 


D272 


P32 


D296 


D312 


D328 


D344 


P40 


D368 


D384 


D400 


P48 
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Table P. 10: Allocation of sub-carrier symbols in NUB for 32 sub-carriers (100 kHz) case 



ETSI TS 100 392-2 V3.3.1 (2008-10) 



10 11 12 13 14 15 If 



17 1? 



19 20 21 22 23 24 25 26 27 28 29 30 31 





1 

2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 

Tj 



SI 


S33 


D1 


D31 


D63 


D95 


PI 


D141 


D173 


D205 


D237 


P17 


D283 


D315 


D347 


D379 


P33 


D425 


D457 


D489 


D521 


P49 


D569 


D601 


D633 


D665 


P65 


D713 


D745 


D777 


P81 


S2 


S34 


D2 


D32 


D64 


D96 


D127 


D142 


D174 


D206 


D238 


D269 


D284 


D316 


D348 


D380 


D411 


D426 


D458 


D490 


D522 


D553 


D570 


D602 


D634 


D666 


D697 


D714 


D746 


D778 


D809 


S3 


S35 


D3 


D33 


D65 


D97 


P2 


D143 


D175 


D207 


D239 


P18 


D285 


D317 


D349 


D381 


P34 


D427 


D459 


D491 


D523 


P50 


D571 


D603 


D635 


D667 


P66 


D715 


D747 


D779 


P82 


S4 


S36 


D4 


D34 


D66 


D98 


D128 


D144 


D176 


D208 


D240 


D270 


D286 


D318 


D350 


D382 


D412 


D428 


D460 


D492 


D524 


D554 


D572 


D604 


D636 


D668 


D698 


D716 


D748 


D780 


D810 


S5 


S37 


D5 


D35 


D67 


D99 


P3 


D145 


D177 


D209 


D241 


P19 


D287 


D319 


D351 


D383 


P35 


D429 


D461 


D493 


D525 


P51 


D573 


D605 


D637 


D669 


P67 


D717 


D749 


D781 


P83 


S6 


S38 


D6 


D36 


D68 


D100 


D129 


D146 


D178 


D210 


D242 


D271 


D288 


D320 


D352 


D384 


D413 


D430 


D462 


D494 


D526 


D555 


D574 


D606 


D638 


D670 


D699 


D718 


D750 


D782 


D811 


S7 


S39 


D7 


D37 


D69 


D101 


P4 


D147 


D179 


D211 


D243 


P20 


D289 


D321 


D353 


D385 


P36 


D431 


D463 


D495 


D527 


P52 


D575 


D607 


D639 


D671 


P68 


D719 


D751 


D783 


P84 


S8 


S40 


D8 


D38 


D70 


D102 


D130 


D148 


D180 


D212 


D244 


D272 


D290 


D322 


D354 


D386 


D414 


D432 


D464 


D496 


D528 


D556 


D576 


D608 


D640 


D672 


D700 


D720 


D752 


D784 


D812 


S9 


S41 


D9 


D39 


D71 


D103 


P5 


D149 


D181 


D213 


D245 


P21 


D291 


D323 


D355 


D387 


P37 


D433 


D465 


D497 


D529 


P53 


D577 


D609 


D641 


D673 


P69 


D721 


D753 


D785 


P85 


S10 


S42 


D10 


D40 


D72 


D104 


D131 


D150 


D182 


D214 


D246 


D273 


D292 


D324 


D356 


D388 


D415 


D434 


D466 


D498 


D530 


D557 


D578 


D610 


D642 


D674 


D701 


D722 


D754 


D786 


D813 


S11 


S43 


D11 


D41 


D73 


D105 


P6 


D151 


D183 


D215 


D247 


P22 


D293 


D325 


D357 


D389 


P38 


D435 


D467 


D499 


D531 


P54 


D579 


D611 


D643 


D675 


P70 


D723 


D755 


D787 


P86 


S12 


S44 


D12 


D42 


D74 


D106 


D132 


D152 


D184 


D216 


D248 


D274 


D294 


D326 


D358 


D390 


D416 


D436 


D468 


D500 


D532 


D558 


D580 


D612 


D644 


D676 


D702 


D724 


D756 


D788 


D814 


S13 


S45 


D13 


D43 


D75 


D107 


P7 


D153 


D185 


D217 


D249 


P23 


D295 


D327 


D359 


D391 


P39 


D437 


D469 


D501 


D533 


P55 


D581 


D613 


D645 


D677 


P71 


D725 


D757 


D789 


P87 


S14 


S46 


HI 


D44 


D76 


D108 


H3 


D154 


D186 


D218 


D250 


H5 


D296 


D328 


D360 


D392 


H7 


D438 


D470 


D502 


D534 


D559 


D582 


D614 


D646 


D678 


D703 


D726 


D758 


D790 


D815 


S15 


S47 


D14 


D45 


D77 


D109 


P8 


D155 


D187 


D219 


D251 


P24 


D297 


D329 


D361 


D393 


P40 


D439 


D471 


D503 


D535 


P56 


D583 


D615 


D647 


D679 


P72 


D727 


D759 


D791 


P88 


S16 


S48 


D15 


D46 


D78 


D110 


D133 


D156 


D188 


D220 


D252 


D275 


D298 


D330 


D362 


D394 


D417 


D440 


D472 


D504 


D536 


D560 


D584 


D616 


D648 


D680 


D704 


D728 


D760 


D792 


D816 


S17 


S49 


Die 


D47 


D79 


Dill 


D134 


D157 


D189 


D221 


D253 


D276 


D299 


D331 


D363 


D395 


D418 


D441 


D473 


D505 


D537 


D561 


D585 


D617 


D649 


D681 


D705 


D729 


D761 


D793 


D817 


S18 


S50 


D17 


D48 


D80 


D112 


P9 


D158 


D190 


D222 


D254 


P25 


D300 


D332 


D364 


D396 


P41 


D442 


D474 


D506 


D538 


P57 


D586 


D618 


D650 


D682 


P73 


D730 


D762 


D794 


P89 


S19 


S51 


H2 


D49 


D81 


D113 


H4 


D159 


D191 


D223 


D255 


H6 


D301 


D333 


D365 


D397 


H8 


D443 


D475 


D507 


D539 


D562 


D587 


D619 


D651 


D683 


D706 


D731 


D763 


D795 


D818 


S20 


S52 


D18 


D50 


D82 


D114 


P10 


D160 


D192 


D224 


D256 


P26 


D302 


D334 


D366 


D398 


P42 


D444 


D476 


D508 


D540 


P58 


D588 


D620 


D652 


D684 


P74 


D732 


D764 


D796 


P90 


S21 


S53 


D19 


D51 


D83 


D115 


D135 


D161 


D193 


D225 


D257 


D277 


D303 


D335 


D367 


D399 


D419 


D445 


D477 


D509 


D541 


D563 


D589 


D621 


D653 


D685 


D707 


D733 


D765 


D797 


D819 


S22 


S54 


D20 


D52 


D84 


D116 


P11 


D162 


D194 


D226 


D258 


P27 


D304 


D336 


D368 


D400 


P43 


D446 


D478 


D510 


D542 


P59 


D590 


D622 


D654 


D686 


P75 


D734 


D766 


D798 


P91 


S23 


S55 


D21 


D53 


D85 


D117 


D136 


D163 


D195 


D227 


D259 


D278 


D305 


D337 


D369 


D401 


D420 


D447 


D479 


D511 


D543 


D564 


D591 


D623 


D655 


D687 


D708 


D735 


D767 


D799 


D820 


S24 


S56 


D22 


D54 


D86 


D118 


P12 


D164 


D196 


D228 


D260 


P28 


D306 


D338 


D370 


D402 


P44 


D448 


D480 


D512 


D544 


P60 


D592 


D624 


D656 


D688 


P76 


D736 


D768 


D800 


P92 


S25 


S57 


D23 


D55 


D87 


D119 


D137 


D165 


D197 


D229 


D261 


D279 


D307 


D339 


D371 


D403 


D421 


D449 


D481 


D513 


D545 


D565 


D593 


D625 


D657 


D689 


D709 


D737 


D769 


D801 


D821 


S26 


S58 


D24 


D56 


D88 


D120 


P13 


D166 


D198 


D230 


D262 


P29 


D308 


D340 


D372 


D404 


P45 


D450 


D482 


D514 


D546 


P61 


D594 


D626 


D658 


D690 


P77 


D738 


D770 


D802 


P93 


S27 


S59 


D25 


D57 


D89 


D121 


D138 


D167 


D199 


D231 


D263 


D280 


D309 


D341 


D373 


D405 


D422 


D451 


D483 


D515 


D547 


D566 


D595 


D627 


D659 


D691 


D710 


D739 


D771 


D803 


D822 


S28 


S60 


D26 


D58 


D90 


D122 


P14 


D168 


D200 


D232 


D264 


P30 


D310 


D342 


D374 


D406 


P46 


D452 


D484 


D516 


D548 


P62 


D596 


D628 


D660 


D692 


P78 


D740 


D772 


D804 


P94 


S29 


S61 


D27 


D59 


D91 


D123 


D139 


D169 


D201 


D233 


D265 


D281 


D311 


D343 


D375 


D407 


D423 


D453 


D485 


D517 


D549 


D567 


D597 


D629 


D661 


D693 


D711 


D741 


D773 


D805 


D823 


S30 


S62 


D28 


D60 


D92 


D124 


P15 


D170 


D202 


D234 


D266 


P31 


D312 


D344 


D376 


D408 


P47 


D454 


D486 


D518 


D550 


P63 


D598 


D630 


D662 


D694 


P79 


D742 


D774 


D806 


P95 


S31 


S63 


D29 


D61 


D93 


D125 


D140 


D171 


D203 


D235 


D267 


D282 


D313 


D345 


D377 


D409 


D424 


D455 


D487 


D519 


D551 


D568 


D599 


D631 


D663 


D695 


D712 


D743 


D775 


D807 


D824 


S32 


S64 


D30 


D62 


D94 


D126 


P16 


D172 


D204 


D236 


D268 


P32 


D314 


D346 


D378 


D410 


P48 


D456 


D488 


D520 


D552 


P64 


D600 


D632 


D664 


D696 


P80 


D744 


D776 


D808 


P96 
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Table P.11 : Allocation of sub-carrier symbols in NUB for 48 sub-carriers (150 kHz) case 



ETSI TS 100 392-2 V3.3.1 (2008-10) 





1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


30 


31 





SI 


S49 


D1 


D47 


D95 


01 43 


PI 


D213 


0261 


O309 


D357 


P25 


0427 


D475 


D523 


0571 


P49 


D641 


0689 


0737 


D785 


P73 


0857 


D905 


D953 


D1001 


P97 


D1073 


01121 


D1169 


P121 


1 


S2 


S50 


D2 


D48 


D96 


01 44 


0191 


D214 


0262 


0310 


D358 


O405 


0428 


D476 


D524 


0572 


D619 


D642 


0690 


0738 


D786 


0833 


0858 


D906 


D954 


D1002 


01 049 


D1074 


01122 


D1170 


01217 


2 


S3 


S51 


D3 


D49 


D97 


0145 


P2 


D215 


0263 


0311 


D359 


P26 


0429 


D477 


D525 


0573 


P50 


D643 


0691 


0739 


D787 


P74 


0859 


D907 


D955 


D1003 


P98 


D1075 


01123 


D1171 


PI 22 


3 


S4 


S52 


D4 


D50 


D98 


0146 


0192 


D216 


0264 


0312 


D360 


O406 


0430 


D478 


D526 


0574 


D620 


D644 


0692 


0740 


D788 


0834 


0860 


D908 


D956 


D1004 


01 050 


D1076 


01124 


D1172 


01218 


4 


S5 


S53 


D5 


D51 


D99 


0147 


P3 


D217 


0265 


0313 


D361 


P27 


0431 


D479 


D527 


0575 


P51 


D645 


0693 


0741 


D789 


P75 


0861 


D909 


D957 


D1005 


P99 


D1077 


01125 


D1173 


PI 23 


5 


SB 


S54 


D6 


D52 


D100 


0148 


0193 


D218 


0266 


0314 


D362 


O407 


0432 


D480 


D528 


0576 


D621 


D646 


0694 


0742 


D790 


0835 


0862 


D910 


D958 


D1006 


O1051 


D1078 


01126 


D1174 


01219 


6 


S7 


S55 


D7 


D53 


Did 


0149 


P4 


D219 


0267 


0315 


D363 


P28 


0433 


D481 


D529 


0577 


P52 


D647 


0695 


0743 


D791 


P76 


0863 


D911 


D959 


D1007 


PI 00 


D1079 


01127 


D1175 


PI 24 


7 


S8 


S56 


D8 


D54 


D102 


0150 


0194 


D220 


0268 


0316 


D364 


O408 


0434 


D482 


D530 


0578 


D622 


D648 


0696 


0744 


D792 


0836 


0864 


D912 


D960 


D1008 


01 052 


D1080 


01128 


D1176 


01220 


8 


S9 


S57 


D9 


D55 


D103 


0151 


P5 


D221 


0269 


0317 


D365 


P29 


0435 


D483 


D531 


0579 


P53 


D649 


0697 


0745 


D793 


P77 


0865 


D913 


D961 


D1009 


P101 


D1081 


01129 


D1177 


PI 25 


9 


S10 


S58 


DIG 


D56 


D104 


0152 


0195 


D222 


0270 


0318 


D366 


O409 


0436 


D484 


D532 


0580 


D623 


D650 


0698 


0746 


D794 


0837 


0866 


D914 


D962 


D1010 


01 053 


D1082 


01 130 


D1178 


01221 


10 


S11 


S59 


D11 


D57 


D105 


0153 


P6 


D223 


0271 


0319 


D367 


P30 


0437 


D485 


D533 


0581 


P54 


D651 


0699 


0747 


D795 


P78 


0867 


D915 


D963 


D1011 


PI 02 


D1083 


01131 


D1179 


PI 26 


11 


S12 


S60 


D12 


D58 


D106 


0154 


0196 


D224 


0272 


0320 


D368 


041 


0438 


D486 


D534 


0582 


D624 


D652 


O700 


0748 


D796 


0838 


0868 


D916 


D964 


D1012 


01 054 


D1084 


01132 


D1180 


01222 


12 


S13 


S61 


D13 


D59 


D107 


0155 


P7 


D225 


0273 


0321 


D369 


P31 


0439 


D487 


D535 


0583 


P55 


D653 


O701 


0749 


D797 


P79 


0869 


D917 


D965 


D1013 


PI 03 


D1085 


01133 


D1181 


PI 27 


13 


S14 


S62 


D14 


D60 


D108 


0156 


0197 


D226 


0274 


0322 


D370 


0411 


0440 


D488 


D536 


0584 


D625 


D654 


O702 


0750 


D798 


0839 


0870 


D918 


D966 


D1014 


01 055 


D1086 


01134 


D1182 


01223 


14 


S15 


S63 


D15 


D61 


D109 


0157 


P8 


D227 


0275 


0323 


D371 


P32 


0441 


D489 


D537 


0585 


P56 


D655 


O703 


0751 


D799 


P80 


0871 


D919 


D967 


D1015 


PI 04 


D1087 


01135 


D1183 


PI 28 


15 


S16 


S64 


Die 


D62 


D110 


0158 


0198 


D228 


0276 


0324 


D372 


0412 


0442 


D490 


D538 


0586 


D626 


D656 


O704 


0752 


D800 


0840 


0872 


D920 


D968 


D1016 


01 056 


D1088 


01136 


D1184 


01224 


16 


S17 


S65 


D17 


D63 


Dill 


0159 


P9 


D229 


0277 


0325 


D373 


P33 


0443 


D491 


D539 


0587 


P57 


D657 


O705 


0753 


D801 


P81 


0873 


D921 


D969 


D1017 


PI 05 


D1089 


01137 


D1185 


PI 29 


17 


S18 


S66 


D18 


D64 


D112 


0160 


0199 


D230 


0278 


0326 


D374 


0413 


0444 


D492 


D540 


0588 


D627 


D658 


O706 


0754 


D802 


0841 


0874 


D922 


D970 


D1018 


01 057 


D1090 


01138 


D1186 


01225 


18 


S19 


S67 


D19 


D65 


D113 


0161 


P10 


D231 


0279 


0327 


D375 


P34 


0445 


D493 


D541 


0589 


P58 


D659 


O707 


0755 


D803 


P82 


0875 


D923 


D971 


D1019 


PI 06 


D1091 


01139 


D1187 


PI 30 


19 


S20 


S68 


D20 


D66 


D114 


0162 


O200 


D232 


0280 


0328 


D376 


0414 


0446 


D494 


D542 


0590 


D628 


D660 


O708 


0756 


D804 


0842 


0876 


D924 


D972 


D1020 


01 058 


D1092 


01 140 


D1188 


01226 


20 


S21 


S69 


D21 


D67 


D115 


0163 


P11 


D233 


0281 


0329 


D377 


P35 


0447 


D495 


D543 


0591 


P59 


D661 


O709 


0757 


D805 


P83 


0877 


D925 


D973 


D1021 


PI 07 


D1093 


01141 


D1189 


P131 


21 


S22 


S70 


HI 


D68 


D116 


0164 


H3 


D234 


0282 


0330 


D378 


H5 


0448 


D496 


D544 


0592 


H7 


D662 


0710 


0758 


D806 


0843 


0878 


D926 


D974 


D1022 


01 059 


D1094 


01142 


D1190 


01227 


22 


S23 


S71 


D22 


D69 


D117 


0165 


P12 


D235 


0283 


0331 


D379 


P36 


0449 


D497 


D545 


0593 


P60 


D663 


0711 


0759 


D807 


P84 


0879 


D927 


D975 


D1023 


PI 08 


D1095 


01143 


D1191 


PI 32 


23 


S24 


S72 


D23 


D70 


D118 


0166 


O201 


D236 


0284 


0332 


D380 


0415 


0450 


D498 


D546 


0594 


D629 


D664 


0712 


0760 


D808 


0844 


0880 


D928 


D976 


D1024 


01 060 


D1096 


01144 


D1192 


01228 


24 


S25 


S73 


D24 


D71 


D119 


0167 


O202 


D237 


0285 


0333 


D381 


0416 


0451 


D499 


D547 


0595 


D630 


D665 


0713 


0761 


D809 


0845 


0881 


D929 


D977 


D1025 


O1061 


D1097 


01145 


D1193 


01229 


25 


S26 


S74 


D25 


D72 


D120 


0168 


P13 


D238 


0286 


0334 


D382 


P37 


0452 


D500 


D548 


0596 


P61 


D666 


0714 


0762 


D810 


P85 


0882 


D930 


D978 


D1026 


PI 09 


D1098 


01146 


D1194 


PI 33 


26 


S27 


S75 


H2 


D73 


D121 


0169 


H4 


D239 


0287 


0335 


D383 


H6 


0453 


D501 


D549 


0597 


H8 


D667 


0715 


0763 


D811 


0846 


0883 


D931 


D979 


D1027 


01 062 


D1099 


01147 


D1195 


01230 


27 


S28 


S76 


D26 


D74 


D122 


0170 


P14 


D240 


0288 


0336 


D384 


P38 


0454 


D502 


D550 


0598 


P62 


D668 


0716 


0764 


D812 


P86 


0884 


D932 


D980 


D1028 


P110 


D1100 


01148 


D1196 


PI 34 


28 


S29 


S77 


D27 


D75 


D123 


0171 


O203 


D241 


0289 


0337 


D385 


0417 


0455 


D503 


D551 


0599 


D631 


D669 


0717 


0765 


D813 


0847 


0885 


D933 


D981 


D1029 


01 063 


D1101 


01149 


D1197 


01231 


29 


S30 


S78 


D28 


D76 


D124 


0172 


P15 


D242 


0290 


0338 


D386 


P39 


0456 


D504 


D552 


O600 


P63 


D670 


0718 


0766 


D814 


P87 


0886 


D934 


D982 


D1030 


Pill 


D1102 


01 150 


D1198 


PI 35 


30 


S31 


S79 


D29 


D77 


D125 


0173 


O204 


D243 


0291 


0339 


D387 


0418 


0457 


D505 


D553 


O601 


D632 


D671 


0719 


0767 


D815 


0848 


0887 


D935 


D983 


D1031 


01 064 


D1103 


01151 


D1199 


01232 


31 


S32 


S80 


D30 


D78 


D126 


0174 


P16 


D244 


0292 


0340 


D388 


P40 


0458 


D506 


D554 


O602 


P64 


D672 


0720 


0768 


D816 


P88 


0888 


D936 


D984 


D1032 


P112 


D1104 


01152 


D1200 


PI 36 


32 


S33 


S81 


D31 


D79 


D127 


0175 


O205 


D245 


0293 


0341 


D389 


0419 


0459 


D507 


D555 


O603 


D633 


D673 


0721 


0769 


D817 


0849 


0889 


D937 


D985 


D1033 


01 065 


D1105 


01153 


D1201 


01233 


33 


S34 


S82 


D32 


D80 


D128 


0176 


P17 


D246 


0294 


0342 


D390 


P41 


0460 


D508 


D556 


O604 


P65 


D674 


0722 


0770 


D818 


P89 


0890 


D938 


D986 


D1034 


P113 


D1106 


01154 


D1202 


PI 37 
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34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
TJ 



S35 


S83 


D33 


D81 


D129 


D177 


D206 


D247 


D295 


D343 


D391 


D420 


D461 


D509 


D557 


D605 


D634 


D675 


D723 


D771 


D819 


D850 


D891 


D939 


D987 


D1035 


D1066 


D1107 


D1155 


D1203 


D1234 


S36 


S84 


D34 


D82 


D130 


D178 


P18 


D248 


D296 


D344 


D392 


P42 


D462 


D510 


D558 


D606 


P66 


D676 


D724 


D772 


D820 


P90 


D892 


D940 


D988 


D1036 


P114 


D1108 


D1156 


D1204 


P138 


S37 


S85 


D35 


D83 


D131 


D179 


D207 


D249 


D297 


D345 


D393 


D421 


D463 


D511 


D559 


D607 


D635 


D677 


D725 


D773 


D821 


D851 


D893 


D941 


D989 


D1037 


D1067 


D1109 


D1157 


D1205 


D1235 


S38 


S86 


D36 


D84 


D132 


D180 


P19 


D250 


D298 


D346 


D394 


P43 


D464 


D512 


D560 


D608 


P67 


D678 


D726 


D774 


D822 


P91 


D894 


D942 


D990 


D1038 


P115 


D1110 


D1158 


D1206 


P139 


S39 


S87 


D37 


D85 


D133 


D181 


D208 


D251 


D299 


D347 


D395 


D422 


D465 


D513 


D561 


D609 


D636 


D679 


D727 


D775 


D823 


D852 


D895 


D943 


D991 


D1039 


D1068 


D1111 


D1159 


D1207 


D1236 


S40 


S88 


D38 


D86 


D134 


D182 


P20 


D252 


D300 


D348 


D396 


P44 


D466 


D514 


D562 


D610 


P68 


D680 


D728 


D776 


D824 


P92 


D896 


D944 


D992 


D1040 


P116 


D1112 


D1160 


D1208 


P140 


S41 


S89 


D39 


D87 


D135 


D183 


D209 


D253 


D301 


D349 


D397 


D423 


D467 


D515 


D563 


D611 


D637 


D681 


D729 


D777 


D825 


D853 


D897 


D945 


D993 


D1041 


D1069 


D1113 


D1161 


D1209 


D1237 


S42 


S90 


D40 


D88 


D136 


D184 


P21 


D254 


D302 


D350 


D398 


P45 


D468 


D516 


D564 


D612 


P69 


D682 


D730 


D778 


D826 


P93 


D898 


D946 


D994 


D1042 


P117 


D1114 


D1162 


D1210 


P141 


S43 


S91 


D41 


D89 


D137 


D185 


D210 


D255 


D303 


D351 


D399 


D424 


D469 


D517 


D565 


D613 


D638 


D683 


D731 


D779 


D827 


D854 


D899 


D947 


D995 


D1043 


D1070 


D1115 


D1163 


D1211 


D1238 


S44 


S92 


D42 


D90 


D138 


D186 


P22 


D256 


D304 


D352 


D400 


P46 


D470 


D518 


D566 


D614 


P70 


D684 


D732 


D780 


D828 


P94 


D900 


D948 


D996 


D1044 


P118 


D1116 


D1164 


D1212 


P142 


S45 


S93 


D43 


D91 


D139 


D187 


D211 


D257 


D305 


D353 


D401 


D425 


D471 


D519 


D567 


D615 


D639 


D685 


D733 


D781 


D829 


D855 


D901 


D949 


D997 


D1045 


D1071 


D1117 


D1165 


D1213 


D1239 


S46 


S94 


D44 


D92 


D140 


D188 


P23 


D258 


D306 


D354 


D402 


P47 


D472 


D520 


D568 


D616 


P71 


D686 


D734 


D782 


D830 


P95 


D902 


D950 


D998 


D1046 


P119 


D1118 


D1166 


D1214 


P143 


S47 


S95 


D45 


D93 


D141 


D189 


D212 


D259 


D307 


D355 


D403 


D426 


D473 


D521 


D569 


D617 


D640 


D687 


D735 


D783 


D831 


D856 


D903 


D951 


D999 


D1047 


D1072 


D1119 


D1167 


D1215 


D1240 


S48 


S96 


D46 


D94 


D142 


D190 


P24 


D260 


D308 


D356 


D404 


P48 


D474 


D522 


D570 


D618 


P72 


D688 


D736 


D784 


D832 


P96 


D904 


D952 


D1000 


D1048 


P120 


D1120 


D1168 


D1216 


P144 
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The allocation of the sub-carrier symbols and their content are presented in table P. 12. 

Table P.12: Normal Uplink Burst (NUB) for QAM 











BNmax 




Channel Bandwidth 


SSSet 

(see note) 


Number of 
SS symbols 


Set content 


4Q 


16Q 


64Q 


Definition 


All 


H1 to H8 


8 


Uplink slot header set 


16 


See clause 8 


25 KHz 


S1 toS16 


16 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 to P24 


24 


Full-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.5 


D1 to D200 


200 


Full-slot uplink data set 


400 


800 


1200 


See clause 8 


50 kHz 


S1 to S32 


32 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 to P48 


48 


Full-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.5 


D1 to D408 


408 


Full-slot uplink data set 


816 1632 2448 


See clause 8 


100 kHz 


S1 to S64 


64 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 to P96 


96 


Full-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.5 


D1 to D824 


824 


Full-slot uplink data set 


1648 3296 4944 


See clause 8 


150 kHz 


S1 to S96 


96 


Uplink sync sequence set 


not applicable 


See clause 9.4.8.3.2 


P1 to PI 44 


144 


Full-slot uplink pilots set 


not applicable 


See clause 9.4.8.3.5 


D1 toD1240 


1240 


Full-slot uplink data set 


2480|4960|7440 


See clause 8 


NOTE: SS is an abbreviation of sub-carrier symbol. 



P.1 .5 Normal Downlink Burst (NDB) 



The allocation of the sub-carrier symbols in the NDB shall be in accordance with tables P. 13 to P. 16. The NDB shall be 
used by the BS to transmit control messages to the MS. 
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Table P. 13: Allocation of sub-carrier symbols in NDB for 8 sub-carriers (25 kHz) case 

-i 



1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


30 


31 


32 


33 


34 


SI 


S9 


D1 


D9 


D17 


P1 


D29 


D37 


D45 


D53 


P5 


D61 


D69 


D77 


D85 


P9 


D93 


D99 


D107 


D115 


P13 


D123 


D129 


D137 


D145 


P17 


D153 


D161 


D169 


D177 


P21 


D185 


D193 


D201 


S2 


HI 


D2 


D10 


D18 


D25 


D30 


D38 


D46 


D54 


H5 


D62 


D70 


D78 


D86 


H9 


D94 


D100 


D108 


D116 


H15 


D124 


D130 


D138 


D146 


H21 


D154 


D162 


D170 


D178 


H25 


D186 


D194 


H29 


S3 


S10 


D3 


D11 


D19 


P2 


D31 


D39 


D47 


D55 


P6 


D63 


D71 


D79 


D87 


P10 


H13 


D101 


D109 


D117 


P14 


H19 


D131 


D139 


D147 


P18 


D155 


D163 


D171 


D179 


P22 


D187 


D195 


D202 


S4 


H2 


D4 


D12 


D20 


D26 


D32 


D40 


D48 


D56 


H6 


D64 


D72 


D80 


D88 


H10 


D95 


D102 


D110 


D118 


H16 


D125 


D132 


DUO 


D148 


H22 


D156 


D164 


D172 


D180 


H26 


D188 


D196 


H30 


S5 


H3 


D5 


D13 


D21 


D27 


D33 


D41 


D49 


D57 


H7 


D65 


D73 


D81 


D89 


H11 


D96 


D103 


Dill 


D119 


H17 


D126 


D133 


D141 


D149 


H23 


D157 


D165 


D173 


D181 


H27 


D189 


D197 


H31 


S6 


S11 


D6 


D14 


D22 


P3 


D34 


D42 


D50 


D58 


P7 


D66 


D74 


D82 


D90 


P11 


H14 


D104 


D112 


D120 


P15 


H20 


D134 


D142 


D150 


P19 


D158 


D166 


D174 


D182 


P23 


D190 


D198 


D203 


S7 


H4 


D7 


D15 


D23 


D28 


D35 


D43 


D51 


D59 


H8 


D67 


D75 


D83 


D91 


H12 


D97 


D105 


D113 


D121 


H18 


D127 


D135 


D143 


D151 


H24 


D159 


D167 


D175 


D183 


H28 


D191 


D199 


H32 


S8 


S12 


D8 


D16 


D24 


P4 


D36 


D44 


D52 


D60 


P8 


D68 


D76 


D84 


D92 


P12 


D98 


D106 


D114 


D122 


P16 


D128 


D136 


D144 


D152 


P20 


D160 


D168 


D176 


D184 


P24 


D192 


D200 


D204 





1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
TJ 



7 8 



Table P.I 4: Allocation of sub-carrier symbols in NDB for 16 sub- 

9 10 11 12 13 14 15 16 17 18 19 20 21 22 



carriers (50 kHz) case 

23 24 25 26 27 28 



29 30 31 32 33 34 



81 


S17 


D5 


D21 


D37 


PI 


D61 


D77 


D93 


D109 


P9 


D129 


D145 


D161 


D177 


P17 


D197 


D211 


D227 


D243 


P25 


D263 


D277 


D293 


D309 


P33 


D329 


D345 


D361 


D377 


P41 


D397 


D413 


D429 


S2 


D1 


D6 


D22 


D38 


D53 


D62 


D78 


D94 


D110 


D125 


D130 


DUO 


D162 


D178 


D193 


D198 


D212 


D228 


D244 


D259 


D264 


D278 


D294 


D310 


D325 


D330 


D346 


D362 


D378 


D393 


D398 


D414 


D430 


S3 


S18 


D7 


D23 


D39 


P2 


D63 


D79 


D95 


Dill 


P10 


D131 


D147 


D163 


D179 


P18 


D199 


D213 


D229 


D245 


P26 


D265 


D279 


D295 


D311 


P34 


D331 


D347 


D363 


D379 


P42 


D399 


D415 


D431 


S4 


D2 


D8 


D24 


D40 


D54 


D64 


D80 


D96 


D112 


D126 


D132 


D148 


D164 


D180 


D194 


D200 


D214 


D230 


D246 


D260 


D266 


D280 


D296 


D312 


D326 


D332 


D348 


D364 


D380 


D394 


D400 


D416 


D432 


S5 


S19 


D9 


D25 


D41 


P3 


D65 


D81 


D97 


D113 


P11 


D133 


D149 


D165 


D181 


P19 


D201 


D215 


D231 


D247 


P27 


D267 


D281 


D297 


D313 


P35 


D333 


D349 


D365 


D381 


P43 


D401 


D417 


D433 


S6 


HI 


D10 


D26 


D42 


D55 


D66 


D82 


D98 


D114 


H5 


D134 


D150 


D166 


D182 


H9 


D202 


D216 


D232 


D248 


H15 


D268 


D282 


D298 


D314 


H21 


D334 


D350 


D366 


D382 


H25 


D402 


D418 


H29 


S7 


S20 


D11 


D27 


D43 


P4 


D67 


D83 


D99 


D115 


P12 


D135 


D151 


D167 


D183 


P20 


H13 


D217 


D233 


D249 


P28 


H19 


D283 


D299 


D315 


P36 


D335 


D351 


D367 


D383 


P44 


D403 


D419 


D434 


S8 


H2 


D12 


D28 


D44 


D56 


D68 


D84 


D100 


D116 


H6 


D136 


D152 


D168 


D184 


H10 


D203 


D218 


D234 


D250 


H16 


D269 


D284 


D300 


D316 


H22 


D336 


D352 


D368 


D384 


H26 


D404 


D420 


H30 


S9 


H3 


D13 


D29 


D45 


D57 


D69 


D85 


D101 


D117 


H7 


D137 


D153 


D169 


D185 


H11 


D204 


D219 


D235 


D251 


H17 


D270 


D285 


D301 


D317 


H23 


D337 


D353 


D369 


D385 


H27 


D405 


D421 


H31 


S10 


S21 


D14 


D30 


D46 


P5 


D70 


D86 


D102 


D118 


P13 


D138 


D154 


D170 


D186 


P21 


H14 


D220 


D236 


D252 


P29 


H20 


D286 


D302 


D318 


P37 


D338 


D354 


D370 


D386 


P45 


D406 


D422 


D435 


S11 


H4 


D15 


D31 


D47 


D58 


D71 


D87 


D103 


D119 


H8 


D139 


D155 


D171 


D187 


H12 


D205 


D221 


D237 


D253 


H18 


D271 


D287 


D303 


D319 


H24 


D339 


D355 


D371 


D387 


H28 


D407 


D423 


H32 


S12 


S22 


D16 


D32 


D48 


P6 


D72 


D88 


D104 


D120 


P14 


D140 


D156 


D172 


D188 


P22 


D206 


D222 


D238 


D254 


P30 


D272 


D288 


D304 


D320 


P38 


D340 


D356 


D372 


D388 


P46 


D408 


D424 


D436 


S13 


D3 


D17 


D33 


D49 


D59 


D73 


D89 


D105 


D121 


D127 


D141 


D157 


D173 


D189 


D195 


D207 


D223 


D239 


D255 


D261 


D273 


D289 


D305 


D321 


D327 


D341 


D357 


D373 


D389 


D395 


D409 


D425 


D437 


S14 


S23 


D18 


D34 


D50 


P7 


D74 


D90 


D106 


D122 


P15 


D142 


D158 


D174 


D190 


P23 


D208 


D224 


D240 


D256 


P31 


D274 


D290 


D306 


D322 


P39 


D342 


D358 


D374 


D390 


P47 


D410 


D426 


D438 


S15 


D4 


D19 


D35 


D51 


D60 


D75 


D91 


D107 


D123 


D128 


D143 


D159 


D175 


D191 


D196 


D209 


D225 


D241 


D257 


D262 


D275 


D291 


D307 


D323 


D328 


D343 


D359 


D375 


D391 


D396 


D411 


D427 


D439 


S16 


S24 


D20 


D36 


D52 


P8 


D76 


D92 


D108 


D124 


P16 


D144 


D160 


D176 


D192 


P24 


D210 


D226 


D242 


D258 


P32 


D276 


D292 


D308 


D324 


P40 


D344 


D360 


D376 


D392 


P48 


D412 


D428 


D440 
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10 11 12 13 14 15 16 17 1? 



19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 





1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

tj 



SI 


S33 


D13 


D45 


D77 


PI 


D125 


D157 


D189 


D221 


P17 


D265 


D297 


D329 


D361 


P33 


D405 


D435 


D467 


D499 


P49 


D543 


D573 


D605 


D637 


P65 


D681 


D713 


D745 


D777 


P81 


D821 


D853 


D885 


S2 


D1 


D14 


D46 


D78 


D109 


D126 


D158 


D190 


D222 


D253 


D266 


D298 


D330 


D362 


D393 


D406 


D436 


D468 


D500 


D531 


D544 


D574 


D606 


D638 


D669 


D682 


D714 


D746 


D778 


D809 


D822 


D854 


D886 


S3 


834 


D15 


D47 


D79 


P2 


D127 


D159 


D191 


D223 


P18 


D267 


D299 


D331 


D363 


P34 


D407 


D437 


D469 


D501 


P50 


D545 


D575 


D607 


D639 


P66 


D683 


D715 


D747 


D779 


P82 


D823 


D855 


D887 


S4 


D2 


D16 


D48 


D80 


D110 


D128 


D160 


D192 


D224 


D254 


D268 


D300 


D332 


D364 


D394 


D408 


D438 


D470 


D502 


D532 


D546 


D576 


D608 


D640 


D670 


D684 


D716 


D748 


D780 


D810 


D824 


D856 


D888 


S5 


835 


D17 


D49 


D81 


P3 


D129 


D161 


D193 


D225 


P19 


D269 


D301 


D333 


D365 


P35 


D409 


D439 


D471 


D503 


P51 


D547 


D577 


D609 


D641 


P67 


D685 


D717 


D749 


D781 


P83 


D825 


D857 


D889 


S6 


D3 


D18 


D50 


D82 


Dill 


D130 


D162 


D194 


D226 


D255 


D270 


D302 


D334 


D366 


D395 


D410 


D440 


D472 


D504 


D533 


D548 


D578 


D610 


D642 


D671 


D686 


D718 


D750 


D782 


D811 


D826 


D858 


D890 


S7 


836 


D19 


D51 


D83 


P4 


D131 


D163 


D195 


D227 


P20 


D271 


D303 


D335 


D367 


P36 


D411 


D441 


D473 


D505 


P52 


D549 


D579 


D611 


D643 


P68 


D687 


D719 


D751 


D783 


P84 


D827 


D859 


D891 


S8 


D4 


D20 


D52 


D84 


D112 


D132 


D164 


D196 


D228 


D256 


D272 


D304 


D336 


D368 


D396 


D412 


D442 


D474 


D506 


D534 


D550 


D580 


D612 


D644 


D672 


D688 


D720 


D752 


D784 


D812 


D828 


D860 


D892 


S9 


837 


D21 


D53 


D85 


P5 


D133 


D165 


D197 


D229 


P21 


D273 


D305 


D337 


D369 


P37 


D413 


D443 


D475 


D507 


P53 


D551 


D581 


D613 


D645 


P69 


D689 


D721 


D753 


D785 


P85 


D829 


D861 


D893 


S10 


D5 


D22 


D54 


D86 


D113 


D134 


D166 


D198 


D230 


D257 


D274 


D306 


D338 


D370 


D397 


D414 


D444 


D476 


D508 


D535 


D552 


D582 


D614 


D646 


D673 


D690 


D722 


D754 


D786 


D813 


D830 


D862 


D894 


S11 


838 


D23 


D55 


D87 


P6 


D135 


D167 


D199 


D231 


P22 


D275 


D307 


D339 


D371 


P38 


D415 


D445 


D477 


D509 


P54 


D553 


D583 


D615 


D647 


P70 


D691 


D723 


D755 


D787 


P86 


D831 


D863 


D895 


S12 


D6 


D24 


D56 


D88 


D114 


D136 


D168 


D200 


D232 


D258 


D276 


D308 


D340 


D372 


D398 


D416 


D446 


D478 


D510 


D536 


D554 


D584 


D616 


D648 


D674 


D692 


D724 


D756 


D788 


D814 


D832 


D864 


D896 


S13 


839 


D25 


D57 


D89 


P7 


D137 


D169 


D201 


D233 


P23 


D277 


D309 


D341 


D373 


P39 


D417 


D447 


D479 


D511 


P55 


D555 


D585 


D617 


D649 


P71 


D693 


D725 


D757 


D789 


P87 


D833 


D865 


D897 


S14 


HI 


D26 


D58 


D90 


D115 


D138 


D170 


D202 


D234 


H5 


D278 


D310 


D342 


D374 


H9 


D418 


D448 


D480 


D512 


H15 


D556 


D586 


D618 


D650 


H21 


D694 


D726 


D758 


D790 


H25 


D834 


D866 


H29 


S15 


840 


D27 


D59 


D91 


P8 


D139 


D171 


D203 


D235 


P24 


D279 


D311 


D343 


D375 


P40 


H13 


D449 


D481 


D513 


P56 


H19 


D587 


D619 


D651 


P72 


D695 


D727 


D759 


D791 


P88 


D835 


D867 


D898 


S16 


H2 


D28 


D60 


D92 


D116 


D140 


D172 


D204 


D236 


H6 


D280 


D312 


D344 


D376 


H10 


D419 


D450 


D482 


D514 


H16 


D557 


D588 


D620 


D652 


H22 


D696 


D728 


D760 


D792 


H26 


D836 


D868 


H30 


S17 


H3 


D29 


D61 


D93 


D117 


D141 


D173 


D205 


D237 


H7 


D281 


D313 


D345 


D377 


H11 


D420 


D451 


D483 


D515 


H17 


D558 


D589 


D621 


D653 


H23 


D697 


D729 


D761 


D793 


H27 


D837 


D869 


H31 


S18 


841 


D30 


D62 


D94 


P9 


D142 


D174 


D206 


D238 


P25 


D282 


D314 


D346 


D378 


P41 


H14 


D452 


D484 


D516 


P57 


H20 


D590 


D622 


D654 


P73 


D698 


D730 


D762 


D794 


P89 


D838 


D870 


D899 


S19 


H4 


D31 


D63 


D95 


D118 


D143 


D175 


D207 


D239 


H8 


D283 


D315 


D347 


D379 


H12 


D421 


D453 


D485 


D517 


H18 


D559 


D591 


D623 


D655 


H24 


D699 


D731 


D763 


D795 


H28 


D839 


D871 


H32 


S20 


842 


D32 


D64 


D96 


P10 


D144 


D176 


D208 


D240 


P26 


D284 


D316 


D348 


D380 


P42 


D422 


D454 


D486 


D518 


P58 


D560 


D592 


D624 


D656 


P74 


D700 


D732 


D764 


D796 


P90 


D840 


D872 


D900 


S21 


D7 


D33 


D65 


D97 


D119 


D145 


D177 


D209 


D241 


D259 


D285 


D317 


D349 


D381 


D399 


D423 


D455 


D487 


D519 


D537 


D561 


D593 


D625 


D657 


D675 


D701 


D733 


D765 


D797 


D815 


D841 


D873 


D901 


S22 


843 


D34 


D66 


D98 


P11 


D146 


D178 


D210 


D242 


P27 


D286 


D318 


D350 


D382 


P43 


D424 


D456 


D488 


D520 


P59 


D562 


D594 


D626 


D658 


P75 


D702 


D734 


D766 


D798 


P91 


D842 


D874 


D902 


S23 


D8 


D35 


D67 


D99 


D120 


D147 


D179 


D211 


D243 


D260 


D287 


D319 


D351 


D383 


D400 


D425 


D457 


D489 


D521 


D538 


D563 


D595 


D627 


D659 


D676 


D703 


D735 


D767 


D799 


D816 


D843 


D875 


D903 


S24 


844 


D36 


D68 


D100 


P12 


D148 


D180 


D212 


D244 


P28 


D288 


D320 


D352 


D384 


P44 


D426 


D458 


D490 


D522 


P60 


D564 


D596 


D628 


D660 


P76 


D704 


D736 


D768 


D800 


P92 


D844 


D876 


D904 


S25 


D9 


D37 


D69 


D101 


D121 


D149 


D181 


D213 


D245 


D261 


D289 


D321 


D353 


D385 


D401 


D427 


D459 


D491 


D523 


D539 


D565 


D597 


D629 


D661 


D677 


D705 


D737 


D769 


D801 


D817 


D845 


D877 


D905 


S26 


845 


D38 


D70 


D102 


P13 


D150 


D182 


D214 


D246 


P29 


D290 


D322 


D354 


D386 


P45 


D428 


D460 


D492 


D524 


P61 


D566 


D598 


D630 


D662 


P77 


D706 


D738 


D770 


D802 


P93 


D846 


D878 


D906 


S27 


D10 


D39 


D71 


D103 


D122 


D151 


D183 


D215 


D247 


D262 


D291 


D323 


D355 


D387 


D402 


D429 


D461 


D493 


D525 


D540 


D567 


D599 


D631 


D663 


D678 


D707 


D739 


D771 


D803 


D818 


D847 


D879 


D907 


S28 


846 


D40 


D72 


D104 


P14 


D152 


D184 


D216 


D248 


P30 


D292 


D324 


D356 


D388 


P46 


D430 


D462 


D494 


D526 


P62 


D568 


D600 


D632 


D664 


P78 


D708 


D740 


D772 


D804 


P94 


D848 


D880 


D908 


S29 


D11 


D41 


D73 


D105 


D123 


D153 


D185 


D217 


D249 


D263 


D293 


D325 


D357 


D389 


D403 


D431 


D463 


D495 


D527 


D541 


D569 


D601 


D633 


D665 


D679 


D709 


D741 


D773 


D805 


D819 


D849 


D881 


D909 


S30 


847 


D42 


D74 


D106 


P15 


D154 


D186 


D218 


D250 


P31 


D294 


D326 


D358 


D390 


P47 


D432 


D464 


D496 


D528 


P63 


D570 


D602 


D634 


D666 


P79 


D710 


D742 


D774 


D806 


P95 


D850 


D882 


D910 


S31 


D12 


D43 


D75 


D107 


D124 


D155 


D187 


D219 


D251 


D264 


D295 


D327 


D359 


D391 


D404 


D433 


D465 


D497 


D529 


D542 


D571 


D603 


D635 


D667 


D680 


D711 


D743 


D775 


D807 


D820 


D851 


D883 


D911 


S32 


848 


D44 


D76 


D108 


P16 


D156 


D188 


D220 


D252 


P32 


D296 


D328 


D360 


D392 


P48 


D434 


D466 


D498 


D530 


P64 


D572 


D604 


D636 


D668 


P80 


D712 


D744 


D776 


D808 


P96 


D852 


D884 


D912 
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1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


18 


19 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


30 


31 


32 


33 


34 





SI 


S49 


D21 


D69 


D117 


PI 


D189 


D237 


D285 


D333 


P25 


D401 


D449 


D497 


D545 


P49 


D613 


D659 


D707 


D755 


P73 


D823 


D869 


D917 


D965 


P97 


D1033 


D1081 


D1129 


D1177 


P121 


D1245 


D1293 


D1341 


1 


S2 


D1 


D22 


D70 


D118 


D165 


D190 


D238 


D286 


D334 


D381 


D402 


D450 


D498 


D546 


D593 


D614 


D660 


D708 


D756 


D803 


D824 


D870 


D918 


D966 


D1013 


D1034 


D1082 


D1130 


D1178 


D1225 


D1246 


D1294 


D1342 


2 


S3 


S50 


D23 


D71 


D119 


P2 


D191 


D239 


D287 


D335 


P26 


D403 


D451 


D499 


D547 


P50 


D615 


D661 


D709 


D757 


P74 


D825 


D871 


D919 


D967 


P98 


D1035 


D1083 


D1131 


D1179 


P122 


D1247 


D1295 


D1343 


3 


S4 


D2 


D24 


D72 


D120 


D166 


D192 


D240 


D288 


D336 


D382 


D404 


D452 


D500 


D548 


D594 


D616 


D662 


D710 


D758 


D804 


D826 


D872 


D920 


D968 


D1014 


D1036 


D1084 


D1132 


D1180 


D1226 


D1248 


D1296 


D1344 


4 


S5 


S51 


D25 


D73 


D121 


P3 


D193 


D241 


D289 


D337 


P27 


D405 


D453 


D501 


D549 


P51 


D617 


D663 


D711 


D759 


P75 


D827 


D873 


D921 


D969 


P99 


D1037 


D1085 


D1133 


D1181 


P123 


D1249 


D1297 


D1345 


5 


S6 


D3 


D26 


D74 


D122 


D167 


D194 


D242 


D290 


D338 


D383 


D406 


D454 


D502 


D550 


D595 


D618 


D664 


D712 


D760 


D805 


D828 


D874 


D922 


D970 


D1015 


D1038 


D1086 


D1134 


D1182 


D1227 


D1250 


D1298 


D1346 


6 


S7 


S52 


D27 


D75 


D123 


P4 


D195 


D243 


D291 


D339 


P28 


D407 


D455 


D503 


D551 


P52 


D619 


D665 


D713 


D761 


P76 


D829 


D875 


D923 


D971 


P100 


D1039 


D1087 


D1135 


D1183 


P124 


D1251 


D1299 


D1347 


7 


SB 


D4 


D28 


D76 


D124 


D168 


D196 


D244 


D292 


D340 


D384 


D408 


D456 


D504 


D552 


D596 


D620 


D666 


D714 


D762 


D806 


D830 


D876 


D924 


D972 


D1016 


D1040 


D1088 


D1136 


D1184 


D1228 


D1252 


D1300 


D1348 


8 


S9 


S53 


D29 


D77 


D125 


P5 


D197 


D245 


D293 


D341 


P29 


D409 


D457 


D505 


D553 


P53 


D621 


D667 


D715 


D763 


P77 


D831 


D877 


D925 


D973 


P101 


D1041 


D1089 


D1137 


D1185 


P125 


D1253 


D1301 


D1349 


9 


S10 


D5 


D30 


D78 


D126 


D169 


D198 


D246 


D294 


D342 


D385 


D410 


D458 


D506 


D554 


D597 


D622 


D668 


D716 


D764 


D807 


D832 


D878 


D926 


D974 


D1017 


D1042 


D1090 


D1138 


D1186 


D1229 


D1254 


D1302 


D1350 


10 


S11 


S54 


D31 


D79 


D127 


P6 


D199 


D247 


D295 


D343 


P30 


D411 


D459 


D507 


D555 


P54 


D623 


D669 


D717 


D765 


P78 


D833 


D879 


D927 


D975 


P102 


D1043 


D1091 


D1139 


D1187 


P126 


D1255 


D1303 


D1351 


11 


S12 


D6 


D32 


D80 


D128 


D170 


D200 


D248 


D296 


D344 


D386 


D412 


D460 


D508 


D556 


D598 


D624 


D670 


D718 


D766 


D808 


D834 


D880 


D928 


D976 


D1018 


D1044 


D1092 


D1140 


D1188 


D1230 


D1256 


D1304 


D1352 


12 


S13 


S55 


D33 


D81 


D129 


P7 


D201 


D249 


D297 


D345 


P31 


D413 


D461 


D509 


D557 


P55 


D625 


D671 


D719 


D767 


P79 


D835 


D881 


D929 


D977 


P103 


D1045 


D1093 


D1141 


D1189 


P127 


D1257 


D1305 


D1353 


13 


S14 


D7 


D34 


D82 


D130 


D171 


D202 


D250 


D298 


D346 


D387 


D414 


D462 


D510 


D558 


D599 


D626 


D672 


D720 


D768 


D809 


D836 


D882 


D930 


D978 


D1019 


D1046 


D1094 


D1142 


D1190 


D1231 


D1258 


D1306 


D1354 


14 


S15 


S56 


D35 


D83 


D131 


P8 


D203 


D251 


D299 


D347 


P32 


D415 


D463 


D511 


D559 


P56 


D627 


D673 


D721 


D769 


P80 


D837 


D883 


D931 


D979 


P104 


D1047 


D1095 


D1143 


D1191 


P128 


D1259 


D1307 


D1355 


15 


S16 


D8 


D36 


D84 


D132 


D172 


D204 


D252 


D300 


D348 


D388 


D416 


D464 


D512 


D560 


D600 


D628 


D674 


D722 


D770 


D810 


D838 


D884 


D932 


D980 


D1020 


D1048 


D1096 


D1144 


D1192 


D1232 


D1260 


D1308 


D1356 


16 


S17 


S57 


D37 


D85 


D133 


P9 


D205 


D253 


D301 


D349 


P33 


D417 


D465 


D513 


D561 


P57 


D629 


D675 


D723 


D771 


P81 


D839 


D885 


D933 


D981 


P105 


D1049 


D1097 


D1145 


D1193 


P129 


D1261 


D1309 


D1357 


17 


S18 


D9 


D38 


D86 


D134 


D173 


D206 


D254 


D302 


D350 


D389 


D418 


D466 


D514 


D562 


D601 


D630 


D676 


D724 


D772 


D811 


D840 


D886 


D934 


D982 


D1021 


D1050 


D1098 


D1146 


D1194 


D1233 


D1262 


D1310 


D1358 


18 


S19 


S58 


D39 


D87 


D135 


P10 


D207 


D255 


D303 


D351 


P34 


D419 


D467 


D515 


D563 


P58 


D631 


D677 


D725 


D773 


P82 


D841 


D887 


D935 


D983 


P106 


D1051 


D1099 


D1147 


D1195 


P130 


D1263 


D1311 


D1359 


19 


S20 


D10 


D40 


D88 


D136 


D174 


D208 


D256 


D304 


D352 


D390 


D420 


D468 


D516 


D564 


D602 


D632 


D678 


D726 


D774 


D812 


D842 


D888 


D936 


D984 


D1022 


D1052 


D1100 


D1148 


D1196 


D1234 


D1264 


D1312 


D1360 


20 


S21 


S59 


D41 


D89 


D137 


P11 


D209 


D257 


D305 


D353 


P35 


D421 


D469 


D517 


D565 


P59 


D633 


D679 


D727 


U//b 


P83 


D843 


D889 


D937 


D985 


P107 


D1053 


D1101 


D1149 


D1197 


P131 


D1265 


D1313 


D1361 


21 


S22 


H1 


D42 


D90 


D138 


D175 


D210 


D258 


D306 


D354 


H5 


D422 


D470 


D518 


D566 


H9 


D634 


D680 


D728 


D776 


H15 


D844 


D890 


D938 


D986 


H21 


D1054 


D1102 


D1150 


D1198 


H25 


D1266 


D1314 


H29 


22 


S23 


S60 


D43 


D91 


D139 


P12 


D211 


D259 


D307 


D355 


P36 


D423 


D471 


D519 


D567 


P60 


H13 


D681 


D729 


U/// 


P84 


H19 


D891 


D939 


D987 


P108 


D1055 


D1103 


D1151 


D1199 


P132 


D1267 


D1315 


D1362 


23 


S24 


H2 


D44 


D92 


D140 


D176 


D212 


D260 


D308 


D356 


H6 


D424 


D472 


D520 


D568 


H10 


D635 


D682 


D730 


D778 


H16 


D845 


D892 


D940 


D988 


H22 


D1056 


D1104 


D1152 


D1200 


H26 


D1268 


D1316 


H30 


24 


S25 


H3 


D45 


D93 


D141 


D177 


D213 


D261 


D309 


D357 


H7 


D425 


D473 


D521 


D569 


H11 


D636 


D683 


D731 


D779 


H17 


D846 


D893 


D941 


D989 


H23 


D1057 


D1105 


D1153 


D1201 


H27 


D1269 


D1317 


H31 


25 


S26 


S61 


D46 


D94 


D142 


P13 


D214 


D262 


D310 


D358 


P37 


D426 


D474 


D522 


D570 


P61 


H14 


D684 


D732 


D780 


P85 


H20 


D894 


D942 


D990 


P109 


D1058 


D1106 


D1154 


D1202 


P133 


D1270 


D1318 


D1363 


26 


S27 


H4 


D47 


D95 


D143 


D178 


D215 


D263 


D311 


D359 


H8 


D427 


D475 


D523 


D571 


H12 


D637 


D685 


D733 


D781 


H18 


D847 


D895 


D943 


D991 


H24 


D1059 


D1107 


D1155 


D1203 


H28 


D1271 


D1319 


H32 


27 


S28 


S62 


D48 


D96 


D144 


P14 


D216 


D264 


D312 


D360 


P38 


D428 


D476 


D524 


D572 


P62 


D638 


D686 


D734 


D782 


P86 


D848 


D896 


D944 


D992 


P110 


D1060 


D1108 


D1156 


D1204 


P134 


D1272 


D1320 


D1364 


28 


S29 


D11 


D49 


D97 


D145 


D179 


D217 


D265 


D313 


D361 


D391 


D429 


D477 


D525 


D573 


D603 


D639 


D687 


D735 


D783 


D813 


D849 


D897 


D945 


D993 


D1023 


D1061 


D1109 


D1157 


D1205 


D1235 


D1273 


D1321 


D1365 


29 


S30 


S63 


D50 


D98 


D146 


P15 


D218 


D266 


D314 


D362 


P39 


D430 


D478 


D526 


D574 


P63 


D640 


D688 


D736 


D784 


P87 


D850 


D898 


D946 


D994 


P111 


D1062 


D1110 


D1158 


D1206 


P135 


D1274 


D1322 


D1366 


30 


S31 


D12 


D51 


D99 


D147 


D180 


D219 


D267 


D315 


D363 


D392 


D431 


D479 


D527 


D575 


D604 


D641 


D689 


D737 


D785 


D814 


D851 


D899 


D947 


D995 


D1024 


D1063 


Dim 


D1159 


D1207 


D1236 


D1275 


D1323 


D1367 


31 


S32 


S64 


D52 


D100 


D148 


P16 


D220 


D268 


D316 


D364 


P40 


D432 


D480 


D528 


D576 


P64 


D642 


D690 


D738 


D786 


P88 


D852 


D900 


D948 


D996 


P112 


D1064 


D1112 


D1160 


D1208 


P136 


D1276 


D1324 


D1368 


32 


S33 


D13 


D53 


D101 


D149 


D181 


D221 


D269 


D317 


D365 


D393 


D433 


D481 


D529 


D577 


D605 


D643 


D691 


D739 


D787 


D815 


D853 


D901 


D949 


D997 


D1025 


D1065 


D1113 


D1161 


D1209 


D1237 


D1277 


D1325 


D1369 


33 


S34 


S65 


D54 


D102 


D150 


P17 


D222 


D270 


D318 


D366 


P41 


D434 


D482 


D530 


D578 


P65 


D644 


D692 


D740 


D788 


P89 


D854 


D902 


D950 


D998 


P113 


D1066 


D1114 


D1162 


D1210 


P137 


D1278 


D1326 


D1370 


34 


S35 


D14 


D55 


D103 


D151 


D182 


D223 


D271 


D319 


D367 


D394 


D435 


D483 


D531 


D579 


D606 


D645 


D693 


D741 


D789 


D816 


D855 


D903 


D951 


D999 


D1026 


D1067 


D1115 


D1163 


D1211 


D1238 


D1279 


D1327 


D1371 


35 


S36 


S66 


D56 


D104 


D152 


P18 


D224 


D272 


D320 


D368 


P42 


D436 


D484 


D532 


D580 


P66 


D646 


D694 


D742 


D790 


P90 


D856 


D904 


D952 


D1000 


P114 


D1068 


D1116 


D1164 


D1212 


P138 


D1280 


D1328 


D1372 


36 


S37 


D15 


D57 


D105 


D153 


D183 


D225 


D273 


D321 


D369 


D395 


D437 


D485 


D533 


D581 


D607 


D647 


D695 


D743 


D791 


D817 


D857 


D905 


D953 


D1001 


D1027 


D1069 


D1117 


D1165 


D1213 


D1239 


D1281 


D1329 


D1373 


37 


S38 


S67 


D58 


D106 


D154 


P19 


D226 


D274 


D322 


D370 


P43 


D438 


D486 


D534 


D582 


P67 


D648 


D696 


D744 


D792 


P91 


D858 


D906 


D954 


D1002 


P115 


D1070 


D1118 


D1166 


D1214 


P139 


D1282 


D1330 


D1374 
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27 28 29 30 31 32 33 34 



38 
39 
40 
41 
42 
43 
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46 
47 
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S39 


D16 


D59 


D107 


D155 


D184 


D227 


D275 


D323 


D371 


D396 


D439 


D487 


D535 


D583 


D608 


D649 


D697 


D745 


D793 


D818 


D859 


D907 


D955 


D1003 


D1028 


D1071 


D1119 


D1167 


D1215 


D1240 


D1283 


D1331 


D1375 


S40 


S68 


D60 


D108 


D156 


P20 


D228 


D276 


D324 


D372 


P44 


D440 


D488 


D536 


D584 


P68 


D650 


D698 


D746 


D794 


P92 


D860 


D908 


D956 


D1004 


P116 


D1072 


D1120 


D1168 


D1216 


PI 40 


D1284 


D1332 


D1376 


S41 


D17 


D61 


D109 


D157 


D185 


D229 


D277 


D325 


D373 


D397 


D441 


D489 


D537 


D585 


D609 


D651 


D699 


D747 


D795 


D819 


D861 


D909 


D957 


D1005 


D1029 


D1073 


D1121 


D1169 


D1217 


D1241 


D1285 


D1333 


D1377 


S42 


S69 


D62 


D110 


D158 


P21 


D230 


D278 


D326 


D374 


P45 


D442 


D490 


D538 


D586 


P69 


D652 


D700 


D748 


D796 


P93 


D862 


D910 


D958 


D1006 


P117 


D1074 


D1122 


D1170 


D1218 


P141 


D1286 


D1334 


D1378 


S43 


D18 


D63 


Dill 


D159 


D186 


D231 


D279 


D327 


D375 


D398 


D443 


D491 


D539 


D587 


D610 


D653 


D701 


D749 


D797 


D820 


D863 


D911 


D959 


D1007 


D1030 


D1075 


D1123 


D1171 


D1219 


D1242 


D1287 


D1335 


D1379 


S44 


S70 


D64 


D112 


D160 


P22 


D232 


D280 


D328 


D376 


P46 


D444 


D492 


D540 


D588 


P70 


D654 


D702 


D750 


D798 


P94 


D864 


D912 


D960 


D1008 


P118 


D1076 


D1124 


D1172 


D1220 


PI 42 


D1288 


D1336 


D1380 


S45 


D19 


D65 


D113 


D161 


D187 


D233 


D281 


D329 


D377 


D399 


D445 


D493 


D541 


D589 


D611 


D655 


D703 


D751 


D799 


D821 


D865 


D913 


D961 


D1009 


D1031 


D1077 


D1125 


D1173 


D1221 


D1243 


D1289 


D1337 


D1381 


S46 


S71 


D66 


D114 


D162 


P23 


D234 


D282 


D330 


D378 


P47 


D446 


D494 


D542 


D590 


P71 


D656 


D704 


D752 


D800 


P95 


D866 


D914 


D962 


D1010 


P119 


D1078 


D1126 


D1174 


D1222 


PI 43 


D1290 


D1338 


D1382 


S47 


D20 


D67 


D115 


D163 


D188 


D235 


D283 


D331 


D379 


D400 


D447 


D495 


D543 


D591 


D612 


D657 


D705 


D753 


D801 


D822 


D867 


D915 


D963 


D1011 


D1032 


D1079 


D1127 


D1175 


D1223 


D1244 


D1291 


D1339 


D1383 


S48 


S72 


D68 


D116 


D164 


P24 


D236 


D284 


D332 


D380 


P48 


D448 


D496 


D544 


D592 


P72 


D658 


D706 


D754 


D802 


P96 


D868 


D916 


D964 


D1012 


PI 20 


D1080 


D1128 


D1176 


D1224 


PI 44 


D1292 


D1340 


D1384 
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The allocation of the sub-carrier symbols and their content are presented in table P. 17. 

Table P.17: Normal Downlink Burst (NDB) for QAM 











BNmax 




Channel Bandwidth 


SSSet 

(see note) 


Number of 
SS symbols 


Set content 


4Q 


16Q 


64Q 


Definition 


All 


HI to H32 


32 


Downlink slot header set 


64 


See clause 8 


25 kHz 


SI toS12 


12 


Downlink sync sequence set 


not applicable 


See clause 9.4.8.3.3 


PI to P24 


24 


Full-slot downlink pilots set 


not applicable 


See clause 9.4.8.3.6 


D1 to D204 


204 


Full-slot downlink data set 


408 


816 


1224 


See clause 8 


50 kHz 


SI to S24 


24 


Downlink sync sequence set 


not applicable 


See clause 9.4.8.3.3 


PI to P48 


48 


Full-slot downlink pilots set 


not applicable 


See clause 9.4.8.3.6 


D1 to D440 


440 


Full-slot downlink data set 


880 1760 2640 


See clause 8 


100 kHz 


S1 to S48 


48 


Downlink sync sequence set 


not applicable 


See clause 9.4.8.3.3 


P1 to P96 


96 


Full-slot downlink pilots set 


not applicable 


See clause 9.4.8.3.6 


D1 to D912 


912 


Full-slot downlink data set 


1824 3648 5472 


See clause 8 


150 kHz 


S1 to S72 


72 


Downlink sync sequence set 


not applicable 


See clause 9.4.8.3.3 


P1 toP144 


144 


Full-slot downlink pilots set 


not applicable 


See clause 9.4.8.3.6 


D1 toD1384 


1384 


Full-slot downlink data set 


2768|5536|8304 


See clause 8 


NOTE: SS is an abbreviation of sub-carrier symbol. 



P.1 .6 Linearization downlink burst (LDB) 

The linearization downlink burst may be used by the BS to linearize its transmitter. Part of the linearization downlink 
burst contains non useful symbols and its timing during the linearization portion shall be determined only by the time 
mask (see clause 6.4.10). 

The allocation of the sub-carrier symbols in the LDB shall be in accordance with tables P. 18 to P. 21. 
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Table P.I 8: Allocation of sub-carrier symbols in LDB for 8 sub-carriers (25 kHz) case 



5 6 7 



9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 



32 



33 



34 



SI 


S9 


Z5 


Z13 


Linearization portion of tlie burst 


FIAI 


FiA9 


FIAI 7 


S2 


Z1 


Z6 


Z14 


FiA2 


FIAIO 


FIAI 8 


S3 


S10 


Z7 


Z15 


FiA3 


FIAII 


FIAI 9 


S4 


Z2 


Z8 


Z16 


FiA4 


FIAI 2 


FiA20 


S5 


Z3 


Z9 


Z17 


FiA5 


FIAI 3 


FiA21 


S6 


S11 


Z10 


Z18 


FiA6 


FIAI 4 


FiA22 


S7 


Z4 


Z11 


Z19 


FiA7 


FIAI 5 


FiA23 


S8 


S12 


Z12 


Z20 


FIAB 


FIAI 6 


FiA24 





1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

Tj 



Table P. 19: Allocation of sub-carrier symbols in LDB for 16 sub-carriers (50 kHz) case 

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 



32 



33 



34 



SI 


S17 


Z9 


Z25 


Linearization portion of the burst 


FiAl 


FIAI 7 


FiA33 


S2 


Z1 


Z10 


Z26 


FiA2 


FIAI 8 


FiA34 


S3 


S18 


Z11 


Z27 


FiA3 


FIAI 9 


FiA35 


S4 


Z2 


Z12 


Z28 


FiA4 


FiA20 


FiA36 


S5 


S19 


Z13 


Z29 


FiA5 


FiA21 


FiA37 


S6 


Z3 


Z14 


Z30 


FiA6 


FiA22 


FiA38 


S7 


S20 


Z15 


Z31 


FiA7 


FiA23 


FiA39 


S8 


Z4 


Z16 


Z32 


FiA8 


FiA24 


FiA40 


S9 


Z5 


Z17 


Z33 


FiA9 


FiA25 


FiA41 


S10 


S21 


Z18 


Z34 


FiAlO 


FiA26 


FiA42 


S11 


Z6 


Z19 


Z35 


FiAII 


FiA27 


FiA43 


S12 


S22 


Z20 


Z36 


FiAl 2 


FiA28 


FiA44 


S13 


Z7 


Z21 


Z37 


FiAl 3 


FiA29 


FiA45 


S14 


S23 


Z22 


Z38 


FiAl 4 


FiA30 


FiA46 


S15 


Z8 


Z23 


Z39 


FiAl 5 


FiA31 


FiA47 


S16 


S24 


Z24 


Z40 


FiAl 6 


FiA32 


FiA48 
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10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 



32 



33 



34 





1 

2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 

tj 



S1 


S33 


Z17 


Z49 


Linearization portion of tlie burst 


FiA1 


FiA33 


FiA65 


S2 


Z1 


Z18 


Z50 


FiA2 


FiA34 


FiA66 


S3 


S34 


Z19 


Z51 


FiA3 


FiA35 


FiA67 


S4 


Z2 


Z20 


Z52 


FiA4 


FiA36 


FiA68 


S5 


S35 


Z21 


Z53 


FiA5 


FiA37 


FiA69 


SB 


Z3 


Z22 


Z54 


FiAe 


FiA38 


FiA70 


S7 


S36 


Z23 


Z55 


FiA7 


FiA39 


FiA71 


S8 


Z4 


Z24 


Z56 


FiA8 


FiA40 


FiA72 


S9 


S37 


Z25 


Z57 


FiA9 


FiA41 


FiA73 


S10 


Z5 


Z26 


Z58 


FiA10 


FiA42 


FiA74 


S11 


S38 


Z27 


Z59 


FiA11 


FiA43 


FiA75 


S12 


Z6 


Z28 


Z60 


FiA12 


FiA44 


FiA76 


S13 


S39 


Z29 


Z61 


FiA13 


FiA45 


FiA77 


S14 


Z7 


Z30 


Z62 


FiA14 


FiA46 


FiA78 


S15 


S40 


Z31 


Z63 


FiA15 


FiA47 


FiA79 


S16 


Z8 


Z32 


Z64 


FiAie 


FiA48 


FiA80 


S17 


Z9 


Z33 


Z65 


FiA17 


FiA49 


FiA81 


S18 


S41 


Z34 


zee 


FiA18 


FiA50 


FiA82 


S19 


Z10 


Z35 


ze7 


FiA19 


FiA51 


FiA83 


S20 


S42 


Z36 


ze8 


FiA20 


FiA52 


FiA84 


S21 


Z11 


Z37 


ze9 


FiA21 


FiA53 


FiA85 


S22 


S43 


Z38 


Z70 


FiA22 


FiA54 


FiA86 


S23 


Z12 


Z39 


Z71 


FiA23 


FiA55 


FiA87 


S24 


S44 


Z40 


Z72 


FiA24 


FiA56 


FiA88 


S25 


Z13 


Z41 


Z73 


FiA25 


FiA57 


FiA89 


S26 


S45 


Z42 


Z74 


FiA2e 


FiA58 


FiA90 


S27 


Z14 


Z43 


Z75 


FiA27 


FiA59 


FiA91 


S28 


S46 


Z44 


Z7e 


FiA28 


FiA60 


FiA92 


S29 


Z15 


Z45 


Z// 


FiA29 


FiA61 


FiA93 


S30 


S47 


Z46 


Z78 


FiA30 


FiA62 


FiA94 


S31 


Z16 


Z47 


Z79 


FiA31 


FiA63 


FiA95 


S32 


S48 


Z48 


Z80 


FiA32 


FiA64 


FiA96 
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5 6 7 



9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 



32 



33 



34 





1 

2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 



SI 


S49 


Z25 


Z73 


Linearization portion of the burst 


FIAI 


FiA49 


FiA97 


S2 


Z1 


Z26 


Z74 


FiA2 


FiA50 


FiA98 


S3 


S50 


Z27 


Z75 


FiA3 


FiA51 


FiA99 


S4 


Z2 


Z28 


Z76 


FiA4 


FiA52 


FiAlOO 


S5 


S51 


Z29 


Z77 


FiA5 


FiA53 


FiAIOI 


S6 


Z3 


Z30 


Z78 


FiA6 


FiA54 


FiA102 


S7 


S52 


Z31 


Z79 


FiA7 


FiA55 


FiA103 


S8 


Z4 


Z32 


Z80 


FiA8 


FiA56 


FiA104 


S9 


S53 


Z33 


Z81 


FiA9 


FiA57 


FiA105 


S10 


Z5 


Z34 


Z82 


FiAlO 


FiA58 


FiAlOe 


S11 


S54 


Z35 


Z83 


FiAII 


FiA59 


FiA107 


S12 


Z6 


Z36 


Z84 


FiA12 


FiA60 


FiA108 


S13 


S55 


Z37 


Z85 


FiA13 


FiA61 


FiA109 


S14 


Z7 


Z38 


Z86 


FiA14 


FiA62 


FiAII 


S15 


S56 


Z39 


Z87 


FiA15 


FiA63 


FiAl 1 1 


S16 


Z8 


Z40 


Z88 


FiA16 


FiA64 


FiAII 2 


S17 


S57 


Z41 


Z89 


FiA17 


FiA65 


FiAII 3 


S18 


Z9 


Z42 


Z90 


FiA18 


FiA66 


FiAII 4 


S19 


S58 


Z43 


Z91 


FiA19 


FiA67 


FiAII 5 


S20 


Z10 


Z44 


Z92 


FiA20 


FiA68 


FiAII 6 


S21 


S59 


Z45 


Z93 


FiA21 


FiA69 


FiAII 7 


S22 


Z11 


Z46 


Z94 


FiA22 


FiA70 


FiAII 8 


S23 


S60 


Z47 


Z95 


FiA23 


FiA71 


FiAII 9 


S24 


Z12 


Z48 


Z96 


FiA24 


FiA72 


FiAl 20 


S25 


Z13 


Z49 


Z97 


FiA25 


FiA73 


FiAl 21 


S26 


S61 


Z50 


Z98 


FiA26 


FiA74 


FiAl 22 


S27 


Z14 


Z51 


Z99 


FiA27 


FiA75 


FiAl 23 


S28 


S62 


Z52 


Z100 


FiA28 


FiA76 


FiAl 24 


S29 


Z15 


Z53 


Z101 


FiA29 


FiA77 


FiAl 25 


S30 


S63 


Z54 


Z102 


FiA30 


FiA78 


FiAl 26 


S31 


Z16 


Z55 


Z103 


FiA31 


FiA79 


FiAl 27 


S32 


S64 


Z56 


Z104 


FiA32 


FiA80 


FiAl 28 


S33 


Z17 


Z57 


Z105 


FiA33 


FiA81 


FiAl 29 


S34 


S65 


Z58 


Z106 


FiA34 


FiA82 


FiAl 30 
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S35 


Z18 


Z59 


Z107 




FiA35 


FiA83 


FiA131 


S36 


S66 


Z60 


Z108 


FiA36 


FiA84 


FiA132 


S37 


Z19 


Z61 


Z109 


FiA37 


FiA85 


FiA133 


S38 


S67 


Z62 


Z110 


FiA38 


FiA86 


FiA134 


S39 


Z20 


Z63 


Z111 


FiA39 


FiA87 


FiA135 


S40 


S68 


Z64 


Z112 


FiA40 


FiA88 


FiA136 


S41 


Z21 


Z65 


Z113 


FiA41 


FiA89 


FiA137 


S42 


S69 


Z66 


Z114 


FiA42 


FiA90 


FiA138 


S43 


Z22 


Z67 


Z115 


FiA43 


FiA91 


FiA139 


S44 


S70 


Z68 


Z116 


FiA44 


FiA92 


FiA140 


S45 


Z23 


Z69 


Z117 


FiA45 


FiA93 


FiA141 


S46 


S71 


Z70 


Z118 


FiA46 


FiA94 


FiA142 


S47 


Z24 


Z71 


Z119 


FiA47 


FiA95 


FiA143 


S48 


S72 


Z72 


Z120 


FiA48 


FiA96 


FiA144 
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The allocation of the sub-carrier symbols and their content are presented in table P.22. 

Table P.22: Linearization Downlinit Burst (LDB) for QAIV! 



Channel Bandwidth 


SSSet 
(see note) 


Number of 
SS symbols 


Set content 


Definition 


25 kHz 


SI toS12 


12 


Downlink sync sequence set 


See clause 9.4.8.3.3 


Z1 to Z2G 


20 


Linearization downlink zeroed set 


See clause 9.4.8.3.8 


FiAl to FAi24 


24 


Filler set A 


See clause 9.4.8.3.7 


50 kHz 


SI to S24 


24 


Downlink sync sequence set 


See clause 9.4.8.3.3 


Z1 to Z40 


40 


Linearization downlink zeroed set 


See clause 9.4.8.3.8 


FiAl to FiA48 


48 


Filler set A 


See clause 9.4.8.3.7 


100 kHz 


SI to S48 


48 


Downlink sync sequence set 


See clause 9.4.8.3.3 


Z1 to Z80 


80 


Linearization downlink zeroed set 


See clause 9.4.8.3.8 


FiAl to FiA96 


96 


Filler set A 


See clause 9.4.8.3.7 


150 kHz 


SI to S72 


72 


Downlink sync sequence set 


See clause 9.4.8.3.3 


Z1 toZ120 


120 


Linearization downlink zeroed set 


See clause 9.4.8.3.8 


FiAl to FiAl 44 


144 


Filler set A 


See clause 9.4.8.3.7 


NOTE: SS is an abbreviation of sub-carrier symbol. 



P. 2 Burst sub-carrier symbol sets 
P.2.1 Uplink sync sequence set 

The numbering and use of this symbol set is defined in clause 9.4.8.3.2. The amplitude of the symbols is as described in 
clause 5.13. The symbol waveform filter independent phases are defined as a multiple of 7i radians. The values of the 
phases shall be as expressed in tables P. 23 to P. 26. 

Table P.23: Uplink sync sequence set USS8 phase values as a multiple of n radians 

USS8 



51 0,67190 

52 -0,83201 

53 0,69601 

54 -0,07206 

55 0,07206 

56 -0,69601 

57 0,83201 

58 -0,67190 

59 0,20310 
SI 0-0,54299 

511 -0,32101 

512 0,19706 
513-0,19706 
S14 0,32101 
SI 5 0,54299 
516-0,20310 
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Table P.24: Uplink sync sequence set USS16 phase values as a multiple of n radians 



USS16 


S1 


0,50431 


S17 


-0,62931 


S2 


-0,23747 


S18 


-0,13753 


S3 


0,41092 


S19 


0,96408 


S4 


-0,36690 


S20 


-0,50810 


S5 


-0,14414 


S21 


-0,98086 


S6 


0,21904 


S22 


0,40596 


S7 


-0,23052 


S23 


0,60552 


S8 


-0,78060 


S24 


0,90560 


S9 


0,78060 


S25 


-0,90560 


S10 


0,23052 


S26 


-0,60552 


S11 


-0,21904 


S27 


-0,40596 


S12 


0,14414 


S28 


0,98086 


S13 


0,36690 


S29 


0,50810 


S14 


-0,41092 


S30 


-0,96408 


S15 


0,23747 


S31 


0,13753 


S16 


-0,50431 


S32 


0,62931 



Table P.25: Uplink sync sequence set USS32 phase values as a multiple of n radians 



USS32 


SI 


-0,43253 


S17 


0,14760 


S33 


0,30753 


S49 


-0,27260 


S2 


-0,57262 


S18 


0,86183 


S34 


0,19762 


S50 


0,76317 


S3 


0,91410 


S19 


-0,25480 


S35 


0,46090 


S51 


-0,37020 


S4 


0,77733 


S20 


-0,89652 


S36 


0,34767 


S52 


0,02152 


S5 


0,63921 


S21 


0,08524 


S37 


0,23579 


S53 


0,78976 


S6 


-0,48052 


S22 


-0,44834 


S38 


-0,89448 


S54 


-0,92666 


S7 


0,38733 


S23 


0,97904 


S39 


-0,01233 


S55 


-0,60404 


S8 


0,81992 


S24 


0,35346 


S40 


-0,69492 


S56 


-0,22846 


S9 


-0,35346 


S25 


-0,81992 


S41 


0,22846 


S57 


0,69492 


S10 


-0,97904 


S26 


-0,38733 


S42 


0,60404 


S58 


0,01233 


S11 


0,44834 


S27 


0,48052 


S43 


0,92666 


S59 


0,89448 


S12 


-0,08524 


S28 


-0,63921 


S44 


-0,78976 


S60 


-0,23579 


S13 


0,89652 


S29 


-0,77733 


S45 


-0,02152 


S61 


-0,34767 


S14 


0,25480 


S30 


-0,91410 


S46 


0,37020 


S62 


-0,46090 


S15 


-0,86183 


S31 


0,57262 


S47 


-0,76317 


S63 


-0,19762 


S16 


-0,14760 


S32 


0,43253 


S48 


0,27260 


S64 


-0,30753 
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Table P.26: Uplink sync sequence set USS48 phase values as a multiple of n radians 



USS48 


S1 


0,03434 


S17 


0,30684 


S33 


-0,73860 


S49 


-0,15934 


S65 


-0,43184 


S81 


0,61360 


S2 


-0,74665 


S18 


0,45957 


S34 


0,16353 


S50 


0,37165 


S66 


-0,83457 


S82 


-0,53853 


S3 


0,64037 


S19 


0,42437 


S35 


-0,71507 


S51 


0,73463 


S67 


0,95063 


S83 


0,09007 


S4 


-0,24758 


S20 


-0,65456 


S36 


0,66230 


S52 


-0,62742 


S68 


-0,22044 


S84 


0,46270 


S5 


-0,11663 


S21 


0,49251 


S37 


-0,46788 


S53 


0,99163 


S69 


0,38249 


S85 


-0,65712 


S6 


0,81293 


S22 


0,86560 


S38 


0,02273 


S54 


-0,18793 


S70 


-0,24060 


S86 


0,60227 


S7 


0,24810 


S23 


0,22977 


S39 


-0,49450 


S55 


0,12690 


S71 


0,14523 


S87 


0,86950 


S8 


0,92339 


S24 


-0,20342 


S40 


-0,60400 


S56 


-0,79839 


S72 


0,32842 


S88 


0,72900 


S9 


0,60400 


S25 


0,20342 


S41 


-0,92339 


S57 


-0,72900 


S73 


-0,32842 


S89 


0,79839 


S10 


0,49450 


S26 


-0,22977 


S42 


-0,24810 


S58 


-0,86950 


S74 


-0,14523 


S90 


-0,12690 


S11 


-0,02273 


S27 


-0,86560 


S43 


-0,81293 


S59 


-0,60227 


S75 


0,24060 


S91 


0,18793 


S12 


0,46788 


S28 


-0,49251 


S44 


0,11663 


S60 


0,65712 


S76 


-0,38249 


S92 


-0,99163 


S13 


-0,66230 


S29 


0,65456 


S45 


0,24758 


S61 


-0,46270 


S77 


0,22044 


S93 


0,62742 


S14 


0,71507 


S30 


-0,42437 


S46 


-0,64037 


S62 


-0,09007 


S78 


-0,95063 


S94 


-0,73463 


S15 


-0,16353 


S31 


-0,45957 


S47 


0,74665 


S63 


0,53853 


S79 


0,83457 


S95 


-0,37165 


S16 


0,73860 


S32 


-0,30684 


S48 


-0,03434 


S64 


-0,61360 


S80 


0,43184 


S96 


0,15934 



P.2.2 Downlink sync sequence set 

The numbering and use of this symbol set is defined in clause 9.4.8.3.3. The amplitude of the symbols is as described in 
clause 5.13.The symbol waveform filter independent phases are defined as a multiple of ti radians. The values of the 
phases shall be as expressed in tables P. 27 to P. 30. 

Table P.27: Downlink sync sequence set DSS8 phase values as a multiple of tt radians 



DSS8 

51 I 0,98180" 

52 0,80687 

53 -0,83599 

54 0,22390 

55 -0,22390 

56 0,83599 

57 -0,80687 

58 -0,98180 

59 -0,10680 
SI 0-0,78901 
S11 0,78901 
SI 2 0,10680 
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Table P.28: Downlink sync sequence set DSS16 phase values as a multiple of tt radians 



DSS16 


S1 


0,69624 


S13 


-0,74070 


S2 


-0,42021 


S14 


0,59028 


S3 


-0,59028 


S15 


0,42021 


S4 


0,74070 


S16 


-0,69624 


S5 


0,98180 


S17 


-0,82124 


S6 


0,80687 


S18 


-0,03472 


S7 


-0,83599 


S19 


-0,10680 


S8 


0,22390 


S20 


-0,78901 


S9 


-0,22390 


S21 


0,78901 


S10 


0,83599 


S22 


0,10680 


S11 


-0,80687 


S23 


0,03472 


S12 


-0,98180 


S24 


0,82124 



Table P.29: Downlink sync sequence set DSS32 phase values as a multiple of tt radians 



DSS32 


SI 


-0,69081 


S13 


0,98180 


S25 


-0,45675 


S37 


-0,07171 


S2 


0,95190 


S14 


0,80687 


S26 


0,97464 


S38 


0,14912 


S3 


0,17230 


S15 


-0,83599 


S27 


-0,50153 


S39 


-0,10680 


S4 


0,99091 


S16 


0,22390 


S28 


0,78198 


S40 


-0,78901 


S5 


-0,78198 


S17 


-0,22390 


S29 


-0,99091 


S41 


0,78901 


S6 


0,50153 


S18 


0,83599 


S30 


-0,17230 


S42 


0,10680 


S7 


-0,97464 


S19 


-0,80687 


S31 


-0,95190 


S43 


-0,14912 


S8 


0,45675 


S20 


-0,98180 


S32 


0,69081 


S44 


0,07171 


S9 


-0,05329 


S21 


0,34018 


S33 


0,56581 


S45 


0,65036 


S10 


-0,55326 


S22 


0,77412 


S34 


-0,79730 


S46 


0,34302 


S11 


-0,77412 


S23 


0,55326 


S35 


-0,34302 


S47 


0,79730 


S12 


-0,34018 


S24 


0,05329 


S36 


-0,65036 


S48 


-0,56581 



Table P.30: Downlink sync sequence set DSS48 phase values as a multiple of n radians 



DSS48 


SI 


-0,42160 


S13 


0,58812 


S25 


-0,22390 


S37 


0,49694 


S49 


0,29660 


S61 


0,78901 


S2 


0,99986 


S14 


0,49850 


S26 


0,83599 


S38 


-0,77020 


S50 


-0,54658 


S62 


0,10680 


S3 


-0,07842 


S15 


0,79337 


S27 


-0,80687 


S39 


0,30147 


S51 


-0,12701 


S63 


0,77546 


S4 


0,81763 


S16 


0,55757 


S28 


-0,98180 


S40 


-0,09935 


S52 


-0,19551 


S64 


-0,06962 


S5 


-0,99799 


S17 


-0,19462 


S29 


-0,22270 


S41 


0,85311 


S53 


-0,22435 


S65 


0,41837 


S6 


0,45136 


S18 


0,78269 


S30 


-0,15046 


S42 


-0,57051 


S54 


0,60480 


S66 


-0,28688 


S7 


0,57051 


S19 


0,15046 


S31 


-0,78269 


S43 


-0,45136 


S55 


0,28688 


S67 


-0,60480 


S8 


-0,85311 


S20 


0,22270 


S32 


0,19462 


S44 


0,99799 


S56 


-0,41837 


S68 


0,22435 


S9 


0,09935 


S21 


0,98180 


S33 


-0,55757 


S45 


-0,81763 


S57 


0,06962 


S69 


0,19551 


S10 


-0,30147 


S22 


0,80687 


S34 


-0,79337 


S46 


0,07842 


S58 


-0,77546 


S70 


0,12701 


S11 


0,77020 


S23 


-0,83599 


S35 


-0,49850 


S47 


-0,99986 


S59 


-0,10680 


S71 


0,54658 


S12 


-0,49694 


S24 


0,22390 


S36 


-0,58812 


S48 


0,42160 


S60 


-0,78901 


S72 


-0,29660 
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P.2.3 Half-slot uplink pilots set 



The numbering and use of this symbol set is defined in clause 9.4.8.3.4. The amplitude of the symbols is as described in 
clause 5.13. The symbol waveform filter independent phases are defined as a multiple of ti radians. The values of the 
phases shall be as expressed in tables P. 31 to P. 34. 

Table P.31 : Half-slot Uplink Pilots Set HUPS8 phase values as a multiple of n radians 

HUPS8 
P1 1-0,77675 



P2 -0,99415 
P3 0,02270 
P4 0,85321 
P5 -0,77675 
P6 -0,99415 
P7 -0,97730 
P8 -0,14679 
P9 0,22325 
RIO 0,00585 
P11 -0,97730 
PI 2 -0,14679 



Table P.32: Half-slot Uplink Pilots Set HUPS16 phase values as a multiple of tt radians 



HUPS 16 


PI 


-0,61834 


P13 


-0,97730 


P2 


0,32487 


P14 


-0,14679 


P3 


-0,77675 


P15 


-0,24886 


P4 


-0,99415 


Pie 


-0,57485 


P5 


0,02270 


P17 


0,38166 


P6 


0,85321 


P18 


-0,67513 


P7 


0,75114 


P19 


0,22325 


P8 


0,42515 


P20 


0,00585 


P9 


-0,61834 


P21 


-0,97730 


P10 


0,32487 


P22 


-0,14679 


P11 


-0,77675 


P23 


-0,24886 


P12 


-0,99415 


P24 


-0,57485 



Table P.33: Half-slot Uplink Pilots Set HUPS32 phase values as a multiple of n radians 



HUPS32 


PI 


-0,68802 


P13 


0,96016 


P25 


-0,97730 


P37 


0,40752 


P2 


0,76268 


P14 


0,02775 


P26 


-0,14679 


P38 


0,63007 


P3 


0,74075 


P15 


0,76268 


P27 


0,98120 


P39 


0,22325 


P4 


0,95335 


P16 


-0,52905 


P28 


0,48894 


P40 


0,00585 


P5 


-0,59248 


P17 


-0,68802 


P29 


-0,03984 


P41 


-0,97730 


P6 


-0,36993 


P18 


0,76268 


P30 


-0,97225 


P42 


-0,14679 


P7 


-0,77675 


P19 


0,74075 


P31 


-0,23732 


P43 


0,98120 


P8 


-0,99415 


P20 


0,95335 


P32 


0,47095 


P44 


0,48894 


P9 


0,02270 


P21 


-0,59248 


P33 


0,31198 


P45 


-0,03984 


P10 


0,85321 


P22 


-0,36993 


P34 


-0,23732 


P46 


-0,97225 


P11 


-0,01880 


P23 


-0,77675 


P35 


-0,25925 


P47 


-0,23732 


P12 


-0,51106 


P24 


-0,99415 


P36 


-0,04665 


P48 


0,47095 
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Table P.34: Half-slot Uplink Pilots Set HUPS48 phase values as a multiple of n radians 



HUPS48 


P1 


0,40869 


P13 


0,02270 


P25 


0,40869 


P37 


-0,97730 


P49 


-0,59131 


P61 


-0,97730 


P2 


-0,95949 


P14 


0,85321 


P26 


-0,95949 


P38 


-0,14679 


P50 


0,04051 


P62 


-0,14679 


P3 


0,19009 


P15 


0,36990 


P27 


0,19009 


P39 


-0,63010 


P51 


-0,80991 


P63 


-0,63010 


P4 


0,43550 


P16 


0,93643 


P28 


0,43550 


P40 


-0,06357 


P52 


-0,56450 


P64 


-0,06357 


P5 


0,32821 


P17 


-0,97339 


P29 


0,32821 


P41 


0,02661 


P53 


-0,67179 


P65 


0,02661 


P6 


0,55944 


P18 


-0,65544 


P30 


0,55944 


P42 


0,34456 


P54 


-0,44056 


P66 


0,34456 


P7 


0,62331 


P19 


-0,24319 


P31 


0,62331 


P43 


0,75681 


P55 


-0,37669 


P67 


0,75681 


P8 


0,17103 


P20 


0,23268 


P32 


0,17103 


P44 


-0,76732 


P56 


-0,82897 


P68 


-0,76732 


P9 


0,50730 


P21 


-0,25551 


P33 


0,50730 


P45 


0,74449 


P57 


-0,49270 


P69 


0,74449 


P10 


0,05567 


P22 


-0,80672 


P34 


0,05567 


P46 


0,19328 


P58 


-0,94433 


P70 


0,19328 


P11 


-0,77675 


P23 


0,56451 


P35 


-0,77675 


P47 


-0,43549 


P59 


0,22325 


P71 


-0,43549 


P12 


-0,99415 


P24 


-0,97755 


P36 


-0,99415 


P48 


0,02245 


P60 


0,00585 


P72 


0,02245 



P.2.4 Full-slot uplink pilots set 



The numbering and use of this symbol set is defined in clause 9.4.8.3.5. The amplitude of the symbols is as described in 
clause 5.13. The symbol waveform filter independent phases are defined as a multiple of ti radians. The values of the 
phases shall be as expressed in tables P. 35 to P. 38. 

Table P.35: Full-slot Uplink Pilots Set FUPS8 phase values as a multiple of tt radians 



FUPS8 
PI 1-0,90175 
P2 0,38085 
P3 0,64770 
P4 0,97821 
P5 0,97325 
P6 -0,24415 
P7 0,27270 
P8 0,10321 
P9 -0,15175 
P10 0,13085 
P11 0,89770 
PI 2 0,22821 
PI 3 -0,77675 
PI 4 -0,99415 
PI 5 0,02270 
PI 6 0,85321 
PI 7 -0,40175 
PI 8 0,88085 
PI 9 0,14770 
P20 0,47821 
P21 0,09825 
P22 -0,61915 
P23 -0,35230 
P24 -0,02179 
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Table P.36: Full-slot Uplink Pilots Set FUPS16 phase values as a multiple of n radians 



FUPS16 


P1 


0,25666 


P25 


-0,61834 


P2 


0,69987 


P26 


0,32487 


P3 


-0,90175 


P27 


-0,77675 


P4 


0,38085 


P28 


-0,99415 


P5 


0,64770 


P29 


0,02270 


P6 


0,97821 


P30 


0,85321 


P7 


0,37614 


P31 


0,75114 


P8 


-0,44985 


P32 


0,42515 


P9 


-0,86834 


P33 


0,75666 


P10 


-0,92513 


P34 


-0,80013 


P11 


0,97325 


P35 


-0,40175 


P12 


-0,24415 


P36 


0,88085 


P13 


0,27270 


P37 


0,14770 


P14 


0,10321 


P38 


0,47821 


P15 


-0,99886 


P39 


-0,12386 


P16 


-0,32485 


P40 


-0,94985 


P17 


-0,99334 


P41 


-0,74334 


P18 


0,44987 


P42 


-0,30013 


P19 


-0,15175 


P43 


0,09825 


P20 


0,13085 


P44 


-0,61915 


P21 


0,89770 


P45 


-0,35230 


P22 


0,22821 


P46 


-0,02179 


P23 


0,62614 


P47 


-0,62386 


P24 


0,80015 


P48 


0,55015 
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Table P.37: Full-slot Uplink Pilots Set FUPS32 phase values as a multiple of n radians 



FUPS32 


P1 


0,18698 


P25 


0,27270 


P49 


-0,68802 


P73 


0,14770 


P2 


-0,86232 


P26 


0,10321 


P50 


0,76268 


P74 


0,47821 


P3 


0,61575 


P27 


0,23120 


P51 


0,74075 


P75 


-0,89380 


P4 


0,32835 


P28 


0,73894 


P52 


0,95335 


P76 


0,11394 


P5 


0,28252 


P29 


-0,78984 


P53 


-0,59248 


P77 


-0,91484 


P6 


0,00507 


P30 


-0,72225 


P54 


-0,36993 


P78 


-0,34725 


P7 


-0,90175 


P31 


-0,98732 


P55 


-0,77675 


P79 


-0,11232 


P8 


0,38085 


P32 


0,72095 


P56 


-0,99415 


P80 


0,09595 


P9 


0,64770 


P33 


0,93698 


P57 


0,02270 


P81 


-0,81302 


P10 


0,97821 


P34 


0,88768 


P58 


0,85321 


P82 


0,13768 


P11 


-0,39380 


P35 


-0,63425 


P59 


-0,01880 


P83 


-0,38425 


P12 


0,61394 


P36 


0,07835 


P60 


-0,51106 


P84 


-0,67165 


P13 


-0,41484 


P37 


-0,96748 


P61 


0,96016 


P85 


-0,71748 


P14 


0,15275 


P38 


-0,24493 


P62 


0,02775 


P86 


-0,99493 


P15 


0,38768 


P39 


-0,15175 


P63 


0,76268 


P87 


0,09825 


P16 


0,59595 


P40 


0,13085 


P64 


-0,52905 


P88 


-0,61915 


P17 


-0,93802 


P41 


0,89770 


P65 


0,68698 


P89 


-0,35230 


P18 


-0,48732 


P42 


0,22821 


P66 


-0,36232 


P90 


-0,02179 


P19 


0,49075 


P43 


-0,14380 


P67 


-0,88425 


P91 


0,60620 


P20 


-0,29665 


P44 


-0,13606 


P68 


0,82835 


P92 


-0,38606 


P21 


-0,84248 


P45 


-0,16484 


P69 


0,78252 


P93 


0,58516 


P22 


0,38007 


P46 


-0,59725 


P70 


0,50507 


P94 


-0,84725 


P23 


0,97325 


P47 


0,63768 


P71 


-0,40175 


P95 


-0,61232 


P24 


-0,24415 


P48 


-0,15405 


P72 


0,88085 


P96 


-0,40405 
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Table P.38: Full-slot Uplink Pilots Set FUPS48 phase values as a multiple of n radians 



FUPS48 


PI 


-0,71631 


P25 


0,15869 


P49 


0,03369 


P73 


0,40869 


P97 


-0,21631 


P121 


0,28369 


P2 


-0,58449 


P26 


-0,20949 


P50 


-0,83449 


P74 


-0,95949 


P98 


-0,08449 


PI 22 


0,41551 


P3 


0,06509 


P27 


-0,05991 


P51 


0,81509 


P75 


0,19009 


P99 


0,56509 


PI 23 


-0,93491 


P4 


-0,18950 


P28 


-0,81450 


P52 


-0,43950 


P76 


0,43550 


PI 00 


0,31050 


PI 24 


0,81050 


P5 


-0,79679 


P29 


0,07821 


P53 


-0,04679 


P77 


0,32821 


P101 


-0,29679 


PI 25 


0,20321 


P6 


0,93444 


P30 


-0,69056 


P54 


0,68444 


P78 


0,55944 


PI 02 


-0,56556 


PI 26 


-0,06556 


P7 


0,49831 


P31 


0,37331 


P55 


-0,75169 


P79 


0,62331 


PI 03 


0,99831 


PI 27 


-0,50169 


P8 


-0,45397 


P32 


0,92103 


P56 


-0,70397 


P80 


0,17103 


PI 04 


0,04603 


PI 28 


0,54603 


P9 


-0,61770 


P33 


0,25730 


P57 


0,13230 


P81 


0,50730 


PI 05 


-0,11770 


PI 29 


0,38230 


P10 


0,43067 


P34 


0,80567 


P58 


0,18067 


P82 


0,05567 


PI 06 


0,93067 


PI 30 


-0,56933 


P11 


-0,90175 


P35 


0,97325 


P59 


-0,15175 


P83 


-0,77675 


PI 07 


-0,40175 


P131 


0,09825 


P12 


0,38085 


P36 


-0,24415 


P60 


0,13085 


P84 


-0,99415 


PI 08 


0,88085 


PI 32 


-0,61915 


P13 


0,64770 


P37 


0,27270 


P61 


0,89770 


P85 


0,02270 


PI 09 


0,14770 


PI 33 


-0,35230 


P14 


0,97821 


P38 


0,10321 


P62 


0,22821 


P86 


0,85321 


P110 


0,47821 


PI 34 


-0,02179 


P15 


-0,00510 


P39 


0,61990 


P63 


0,24490 


P87 


0,36990 


Pill 


-0,50510 


PI 35 


0,99490 


P16 


0,06143 


P40 


0,18643 


P64 


-0,68857 


P88 


0,93643 


P112 


-0,43857 


PI 36 


-0,93857 


P17 


-0,34839 


P41 


-0,72339 


P65 


-0,09839 


P89 


-0,97339 


P113 


-0,84839 


PI 37 


0,65161 


P18 


-0,53044 


P42 


0,59456 


P66 


0,71956 


P90 


-0,65544 


P114 


0,96956 


PI 38 


0,46956 


P19 


-0,61819 


P43 


0,00681 


P67 


-0,36819 


P91 


-0,24319 


P115 


0,88181 


PI 39 


0,38181 


P20 


-0,64232 


P44 


-0,51732 


P68 


0,60768 


P92 


0,23268 


P116 


0,85768 


PI 40 


0,35768 


P21 


0,36949 


P45 


-0,00551 


P69 


0,61949 


P93 


-0,25551 


P117 


-0,13051 


P141 


-0,63051 


P22 


-0,68172 


P46 


0,44328 


P70 


0,56828 


P94 


-0,80672 


P118 


0,81828 


PI 42 


0,31828 


P23 


0,18951 


P47 


0,81451 


P71 


0,43951 


P95 


0,56451 


P119 


-0,31049 


PI 43 


-0,81049 


P24 


0,14745 


P48 


0,27245 


P72 


-0,60255 


P96 


-0,97755 


PI 20 


-0,35255 


PI 44 


-0,85255 
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P.2.5 Full-slot downlink pilots set 



The numbering and use of this symbol set is defined in clause 9.4.8.3.5. The amplitude of the symbols is as described in 
clause 5.13. The symbol waveform filter independent phases are defined as a multiple of ti radians. The values of the 
phases shall be as expressed in tables P. 39 to P.42. 

Table P.39: Downlink Pilots Set FDPS8 phase values as a multiple of tt radians 

FDPS8 
P1 1-0,77675 



P2 -0,99415 
P3 0.02270 
P4 0,85321 
P5 0,96985 
P6 -0,57733 
P7 0,57733 
P8 -0,96985 
P9 -0,02675 
RIO 0,75585 
P11 0,27270 
P12 0,10321 
P13 -0,65175 
P14 -0,36915 
PI 5 -0,60230 
PI 6 0,72821 
PI 7 -0,27675 
PI 8 -0,49415 
PI 9 -0,47730 
P20 0,35321 
P21 0,09825 
P22 -0,61915 
P23 -0,35230 
P24 -0,02179 
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Table P.40: Downlink Pilots Set FDPS16 phase values as a multiple of tt radians 



FDPS16 


P1 


-0,61834 


P25 


0,50666 


P2 


0,32487 


P26 


-0,05013 


P3 


-0,77675 


P27 


-0,65175 


P4 


-0,99415 


P28 


-0,36915 


P5 


0,02270 


P29 


-0,60230 


P6 


0,85321 


P30 


0,72821 


P7 


0,75114 


P31 


-0,87386 


P8 


0,42515 


P32 


-0,69985 


P9 


-0,31839 


P33 


-0,11834 


P10 


-0,64267 


P34 


0,82487 


P11 


0,96985 


P35 


-0,27675 


P12 


-0,57733 


P36 


-0,49415 


P13 


0,57733 


P37 


-0,47730 


P14 


-0,96985 


P38 


0,35321 


P15 


-0,22663 


P39 


0,25114 


P16 


-0,93193 


P40 


-0,07485 


P17 


0,13166 


P41 


-0,74334 


P18 


0,07487 


P42 


-0,30013 


P19 


-0,02675 


P43 


0,09825 


P20 


0,75585 


P44 


-0,61915 


P21 


0,27270 


P45 


-0,35230 


P22 


0,10321 


P46 


-0,02179 


P23 


-0,99886 


P47 


-0,62386 


P24 


-0,32485 


P48 


0,55015 
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Table P.41 : Downlink Pilots Set FDPS32 phase values as a multiple of tt radians 



FDPS32 


P1 


-0,68802 


P25 


0,57733 


P49 


0,43698 


P73 


-0,47730 


P2 


0,76268 


P26 


-0,96985 


P50 


0,38768 


P74 


0,35321 


P3 


0,74075 


P27 


0,71089 


P51 


0,86575 


P75 


-0,51880 


P4 


0,95335 


P28 


0,78770 


P52 


-0,42165 


P76 


0,98894 


P5 


-0,59248 


P29 


-0,39755 


P53 


0,53252 


P77 


0,46016 


P6 


-0,36993 


P30 


-0,56099 


P54 


-0,74493 


P78 


-0,47225 


P7 


-0,77675 


P31 


0,80111 


P55 


-0,65175 


P79 


0,26268 


P8 


-0,99415 


P32 


0,35060 


P56 


-0,36915 


P80 


0,97095 


P9 


0,02270 


P33 


0,06198 


P57 


-0,60230 


P81 


-0,81302 


P10 


0,85321 


P34 


0,51268 


P58 


0,72821 


P82 


0,13768 


P11 


-0,01880 


P35 


-0,50925 


P59 


0,35620 


P83 


-0,38425 


P12 


-0,51106 


P36 


0,70335 


P60 


0,36394 


P84 


-0,67165 


P13 


0,96016 


P37 


0,15752 


P61 


0,33516 


P85 


-0,71748 


P14 


0,02775 


P38 


-0,61993 


P62 


-0,09725 


P86 


-0,99493 


P15 


0,76268 


P39 


-0,02675 


P63 


-0,86232 


P87 


0,09825 


P16 


-0,52905 


P40 


0,75585 


P64 


0,34595 


P88 


-0,61915 


P17 


-0,36875 


P41 


0,27270 


P65 


-0,18802 


P89 


-0,35230 


P18 


0,69641 


P42 


0,10321 


P66 


-0,73732 


P90 


-0,02179 


P19 


-0,76835 


P43 


0,23120 


P67 


-0,75925 


P91 


0,60620 


P20 


-0,45208 


P44 


0,73894 


P68 


-0,54665 


P92 


-0,38606 


P21 


0,45770 


P45 


-0,78984 


P69 


-0,09248 


P93 


0,58516 


P22 


-0,43225 


P46 


-0,72225 


P70 


0,13007 


P94 


-0,84725 


P23 


0,96985 


P47 


-0,98732 


P71 


-0,27675 


P95 


-0,61232 


P24 


-0,57733 


P48 


0,72095 


P72 


-0,49415 


P96 


-0,40405 
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Table P.42: Downlink Pilots Set FDPS48 phase values as a multiple of tt radians 



FDPS48 


P1 


0,40869 


P25 


-0,95923 


P49 


-0,84131 


P73 


-0,46631 


P97 


0,90869 


P121 


0,28369 


P2 


-0,95949 


P26 


-0,19966 


P50 


0,79051 


P74 


0,66551 


P98 


-0,45949 


PI 22 


0,41551 


P3 


0,19009 


P27 


0,72691 


P51 


0,94009 


P75 


0,31509 


P99 


0,69009 


PI 23 


-0,93491 


P4 


0,43550 


P28 


0,00502 


P52 


0,18550 


P76 


-0,93950 


PI 00 


0,93550 


PI 24 


0,81050 


P5 


0,32821 


P29 


-0,54264 


P53 


-0,92179 


P77 


-0,54679 


P101 


0,82821 


PI 25 


0,20321 


P6 


0,55944 


P30 


0,71870 


P54 


0,30944 


P78 


0,18444 


PI 02 


-0,94056 


PI 26 


-0,06556 


P7 


0,62331 


P31 


0,80411 


P55 


-0,62669 


P79 


0,74831 


PI 03 


-0,87669 


PI 27 


-0,50169 


P8 


0,17103 


P32 


-0,13019 


P56 


-0,07897 


P80 


0,79603 


PI 04 


0,67103 


PI 28 


0,54603 


P9 


0,50730 


P33 


0,75959 


P57 


-0,74270 


P81 


-0,36770 


PI 05 


-0,99270 


PI 29 


0,38230 


P10 


0,05567 


P34 


-0,51745 


P58 


-0,19433 


P82 


-0,31933 


PI 06 


0,55567 


PI 30 


-0,56933 


P11 


-0,77675 


P35 


0,96985 


P59 


-0,02675 


P83 


-0,65175 


PI 07 


-0,27675 


P131 


0,09825 


P12 


-0,99415 


P36 


-0,57733 


P60 


0,75585 


P84 


-0,36915 


PI 08 


-0,49415 


PI 32 


-0,61915 


P13 


0,02270 


P37 


0,57733 


P61 


0,27270 


P85 


-0,60230 


PI 09 


-0,47730 


PI 33 


-0,35230 


P14 


0,85321 


P38 


-0,96985 


P62 


0,10321 


P86 


0,72821 


P110 


0,35321 


PI 34 


-0,02179 


P15 


0,36990 


P39 


-0,70486 


P63 


0,61990 


P87 


0,74490 


Pill 


-0,13010 


PI 35 


0,99490 


P16 


0,93643 


P40 


-0,17845 


P64 


0,18643 


P88 


-0,18857 


P112 


0,43643 


PI 36 


-0,93857 


P17 


-0,97339 


P41 


0,97135 


P65 


-0,72339 


P89 


0,40161 


P113 


0,52661 


PI 37 


0,65161 


P18 


-0,65544 


P42 


-0,00409 


P66 


0,59456 


P90 


-0,78044 


P114 


0,84456 


PI 38 


0,46956 


P19 


-0,24319 


P43 


-0,12898 


P67 


0,00681 


P91 


0,13181 


P115 


-0,74319 


PI 39 


0,38181 


P20 


0,23268 


P44 


-0,46624 


P68 


-0,51732 


P92 


-0,89232 


P116 


-0,26732 


PI 40 


0,35768 


P21 


-0,25551 


P45 


-0,86440 


P69 


-0,00551 


P93 


-0,88051 


P117 


-0,75551 


P141 


-0,63051 


P22 


-0,80672 


P46 


-0,68654 


P70 


0,44328 


P94 


-0,93172 


P118 


0,69328 


PI 42 


0,31828 


P23 


0,56451 


P47 


-0,46720 


P71 


0,81451 


P95 


0,93951 


P119 


0,06451 


PI 43 


-0,81049 


P24 


-0,97755 


P48 


0,83510 


P72 


0,27245 


P96 


-0,10255 


PI 20 


0,52245 


PI 44 


-0,85255 
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P.2.6 Filler sets 

The numbering and use of these symbol sets are defined in clause 9.4.8.3.7. The amplitude of the symbols is as 
described in clause 5.13. The symbol waveform filter independent phases are defined as a multiple of ti radians. The 
values of the phases shall be as expressed in tables P. 43 to P. 50. 

Table P.43: Filler Set A FiSA8 phase values as a multiple of tt radians 



FiSA8 
FiA1 10,75204 



FiA2 



■0,58430 



FiA3 
FiA4 
FiA5 



0,95743 
0,49625 
0,50375 



FiA6 



0,04257 



FiA7 
FiA8 
FiA9 



-0,41570 
0,24796 
-0,50000 



FiAlO 



0,50000 



FiA11 
FiA12 
FiA13 



-0,50000 
-0,50000 
-0,50000 



FiA14 



■0,50000 



FiA15 
FiA16 
FiA17 



0,50000 
-0,50000 
0,24796 



FiA18 



■0,41570 



FiA19 
FiA20 
FiA21 



0,04257 
0,50375 
0,49625 



FiA22 



0,95743 



FiA23 
FiA24 



-0,58430 
0,75204 
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Table P.44: Filler Set A FiSA16 phase values as a multiple of n radians 



FiSA16 


FiA1 


-0,75639 


FiA25 


0,50000 


FiA2 


-0,36021 


FiA26 


-0,50000 


FiA3 


0,82607 


FiA27 


-0,50000 


FiA4 


0,50316 


FiA28 


0,50000 


FiA5 


-0,73390 


FiA29 


-0,50000 


FiA6 


0,77596 


FiA30 


0,50000 


FiA7 


-0,77875 


FiA31 


0,50000 


FiA8 


0,08003 


FiA32 


0,50000 


FiA9 


0,91997 


FiA33 


-0,24361 


FiA10 


-0,22125 


FiA34 


-0,63979 


FiA11 


0,22404 


FiA35 


0,17393 


FiA12 


-0,26610 


FiA36 


0,49684 


FiA13 


0,49684 


FiA37 


-0,26610 


FiA14 


0,17393 


FiA38 


0,22404 


FiA15 


-0,63979 


FiA39 


-0,22125 


FiA16 


-0,24361 


FiA40 


0,91997 


FiA17 


0,50000 


FiA41 


0,08003 


FiA18 


0,50000 


FiA42 


-0,77875 


FiA19 


0,50000 


FiA43 


0,77596 


FiA20 


-0,50000 


FiA44 


-0,73390 


FiA21 


0,50000 


FiA45 


0,50316 


FiA22 


-0,50000 


FiA46 


0,82607 


FiA23 


-0,50000 


FiA47 


-0,36021 


FiA24 


0,50000 


FiA48 


-0,75639 



Table P.45: Filler Set A FiSA32 phase values as a multiple of tt radians 



FiSA32 


FiAl 


0,01334 


FiA25 


0,60533 


FiA49 


-0,50000 


FiA73 


-0,47455 


FiA2 


0,55821 


FiA26 


0,48932 


FiA50 


-0,50000 


FiA74 


0,91276 


FiA3 


0,42374 


FiA27 


-0,44554 


FiA51 


0,50000 


FiA75 


-0,45073 


FiA4 


-0,05004 


FiA28 


-0,08948 


FiA52 


0,50000 


FiA76 


-0,69412 


FiA5 


-0,91052 


FiA29 


-0,94996 


FiA53 


-0,50000 


FiA77 


-0,66409 


FiA6 


-0,55446 


FiA30 


0,57626 


FiA54 


-0,50000 


FiA78 


-0,16860 


FiA7 


0,51068 


FiA31 


0,44179 


FiA55 


-0,50000 


FiA79 


0,36719 


FiA8 


0,39467 


FiA32 


0,98666 


FiA56 


-0,50000 


FiA80 


-0,80037 


FiA9 


-0,52545 


FiA33 


0,50000 


FiA57 


-0,50000 


FiA81 


-0,19963 


FiAlO 


0,08724 


FiA34 


0,50000 


FiA58 


-0,50000 


FiA82 


0,63281 


FiAII 


-0,54927 


FiA35 


-0,50000 


FiA59 


0,50000 


FiA83 


-0,83140 


FiAl 2 


-0,30588 


FiA36 


0,50000 


FiA60 


-0,50000 


FiA84 


-0,33591 


FiAl 3 


-0,33591 


FiA37 


-0,50000 


FiA61 


0,50000 


FiA85 


-0,30588 


FiAl 4 


-0,83140 


FiA38 


0,50000 


FiA62 


-0,50000 


FiA86 


-0,54927 


FiAl 5 


0,63281 


FiA39 


-0,50000 


FiA63 


0,50000 


FiA87 


0,08724 


FiAl 6 


-0,19963 


FiA40 


-0,50000 


FiA64 


0,50000 


FiA88 


-0,52545 


FiAl 7 


-0,80037 


FiA41 


-0,50000 


FiA65 


0,98666 


FiA89 


0,39467 


FiAl 8 


0,36719 


FiA42 


-0,50000 


FiA66 


0,44179 


FiA90 


0,51068 


FiAl 9 


-0,16860 


FiA43 


-0,50000 


FiA67 


0,57626 


FiA91 


-0,55446 


FiA20 


-0,66409 


FiA44 


-0,50000 


FiA68 


-0,94996 


FiA92 


-0,91052 


FiA21 


-0,69412 


FiA45 


0,50000 


FiA69 


-0,08948 


FiA93 


-0,05004 


FiA22 


-0,45073 


FiA46 


0,50000 


FiA70 


-0,44554 


FiA94 


0,42374 


FiA23 


0,91276 


FiA47 


-0,50000 


FiA71 


0,48932 


FiA95 


0,55821 


FiA24 


-0,47455 


FiA48 


-0,50000 


FiA72 


0,60533 


FiA96 


0,01334 
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Table P.46: Filler Set A FiSA48 phase values as a multiple of n radians 



FiSA48 


FiA1 


0,12836 


FiA25 


0,19698 


FiA49 


-0,50000 


FiA73 


-0,50000 


FiA97 


0,87164 


FiA121 


0,80302 


FiA2 


-0,84195 


FiA26 


-0,26635 


FiA50 


-0,50000 


FiA74 


0,50000 


FiA98 


-0,15805 


FiA122 


-0,73365 


FiA3 


0,91084 


FiA27 


-0,19250 


FiA51 


-0,50000 


FiA75 


-0,50000 


FiA99 


0,08916 


FiA123 


-0,80750 


FiA4 


-0,14609 


FiA28 


0,15926 


FiA52 


0,50000 


FiA76 


0,50000 


FiAlOO 


-0,85391 


FiA124 


0,84074 


FiA5 


0,15839 


FiA29 


-0,19669 


FiA53 


-0,50000 


FiA77 


0,50000 


FiAIOI 


0,84161 


FiA125 


-0,80331 


FiA6 


0,06634 


FiA30 


-0,75652 


FiA54 


-0,50000 


FiA78 


0,50000 


FiA102 


0,93366 


FiA126 


-0,24348 


FiA7 


-0,82586 


FiA31 


-0,17711 


FiA55 


-0,50000 


FiA79 


-0,50000 


FiA103 


-0,17414 


FiA127 


-0,82289 


FiA8 


-0,34694 


FiA32 


-0,13511 


FiA56 


0,50000 


FiA80 


0,50000 


FiA104 


-0,65306 


FiA128 


-0,86489 


FiA9 


0,22480 


FiA33 


-0,17785 


FiA57 


0,50000 


FiA81 


0,50000 


FiA105 


0,77520 


FiA129 


-0,82215 


FiA10 


-0,41949 


FiA34 


-0,29517 


FiA58 


-0,50000 


FiA82 


0,50000 


FiA106 


-0,58051 


FiA130 


-0,70483 


FiA11 


-0,25113 


FiA35 


0,60773 


FiA59 


0,50000 


FiA83 


0,50000 


FiA107 


-0,74887 


FiA131 


0,39227 


FiA12 


0,63543 


FiA36 


-0,11453 


FiA60 


-0,50000 


FiA84 


-0,50000 


FiA108 


0,36457 


FiA132 


-0,88547 


FiA13 


-0,88547 


FiA37 


0,36457 


FiA61 


-0,50000 


FiA85 


-0,50000 


FiA109 


-0,11453 


FiA133 


0,63543 


FiA14 


0,39227 


FiA38 


-0,74887 


FiA62 


0,50000 


FiA86 


0,50000 


FiAIIO 


0,60773 


FiA134 


-0,25113 


FiA15 


-0,70483 


FiA39 


-0,58051 


FiA63 


0,50000 


FiA87 


-0,50000 


FiAIII 


-0,29517 


FiA135 


-0,41949 


FiA16 


-0,82215 


FiA40 


0,77520 


FiA64 


0,50000 


FiA88 


0,50000 


FiA112 


-0,17785 


FiA136 


0,22480 


FiA17 


-0,86489 


FiA41 


-0,65306 


FiA65 


0,50000 


FiA89 


0,50000 


FiA113 


-0,13511 


FiA137 


-0,34694 


FiA18 


-0,82289 


FiA42 


-0,17414 


FiA66 


-0,50000 


FiA90 


-0,50000 


FiA114 


-0,17711 


FiA138 


-0,82586 


FiA19 


-0,24348 


FiA43 


0,93366 


FiA67 


0,50000 


FiA91 


-0,50000 


FiA115 


-0,75652 


FiA139 


0,06634 


FiA20 


-0,80331 


FiA44 


0,84161 


FiA68 


0,50000 


FiA92 


-0,50000 


FiA116 


-0,19669 


FiA140 


0,15839 


FiA21 


0,84074 


FiA45 


-0,85391 


FiA69 


0,50000 


FiA93 


0,50000 


FiA117 


0,15926 


FiA141 


-0,14609 


FiA22 


-0,80750 


FiA46 


0,08916 


FiA70 


-0,50000 


FiA94 


-0,50000 


FiA118 


-0,19250 


FiA142 


0,91084 


FiA23 


-0,73365 


FiA47 


-0,15805 


FiA71 


0,50000 


FiA95 


-0,50000 


FiA119 


-0,26635 


FiA143 


-0,84195 


FiA24 


0,80302 


FiA48 


0,87164 


FiA72 


-0,50000 


FiA96 


-0,50000 


FiA120 


0,19698 


FiA144 


0,12836 
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Table P.47: Filler Set B FiSBS phase values as a multiple of n radians 



FiSB8 


FiB1 


0,87704 


FiB2 


-0,20930 


FiB3 


-0,41757 


FiB4 


-0,62875 


FiB5 


-0,37125 


FiB6 


-0,58243 


FiB7 


-0,79070 


FiB8 


0,12296 


FiB9 


-0,37500 


FiB10 


0,87500 


FiB11 


0,12500 


FiB12 


0,37500 


FiB13 


0,62500 


FiB14 


0,87500 


FiB15 


0,12500 


FiB16 


-0,62500 


FiB17 


0,37296 


FiB18 


-0,04070 


FiB19 


0,66757 


FiB20 


-0,62125 


FiB21 


-0,37875 


FiB22 


0,33243 


FiB23 


-0,95930 


FiB24 


0,62704 
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Table P.48: Filler Set B FiSB16 phase values as a multiple of n radians 



FiSBW 


FiB1 


0,36861 


FiB25 


-0,37500 


FiB2 


-0,98521 


FiB26 


0,87500 


FiB3 


0,45107 


FiB27 


-0,87500 


FiB4 


0,37816 


FiB28 


0,37500 


FiB5 


-0,60890 


FiB29 


-0,37500 


FiB6 


-0,84904 


FiB30 


0,87500 


FiB7 


-0,15375 


FiB31 


-0,87500 


FiB8 


0,95503 


FiB32 


-0,62500 


FiB9 


0,04497 


FiB33 


0,88139 


FiB10 


-0,84625 


FiB34 


0,73521 


FiB11 


-0,15096 


FiB35 


-0,20107 


FiB12 


-0,39110 


FiB36 


0,37184 


FiB13 


0,62184 


FiB37 


-0,14110 


FiB14 


0,54893 


FiB38 


0,59904 


FiB15 


-0,01479 


FiB39 


0,40375 


FiB16 


0,63139 


FiB40 


-0,20503 


FiB17 


-0,37500 


FiB41 


-0,79497 


FiB18 


-0,12500 


FiB42 


0,59625 


FiB19 


0,12500 


FiB43 


0,40096 


FiB20 


-0,62500 


FiB44 


-0,85890 


FiB21 


0,62500 


FiB45 


0,62816 


FiB22 


-0,12500 


FiB46 


-0,79893 


FiB23 


0,12500 


FiB47 


0,26479 


FiB24 


-0,62500 


FiB48 


0,11861 
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Table P.49: Filler Set B FiSB32 phase values as a multiple of n radians 



FiSB32 


FiB1 


-0,86166 


FiB25 


-0,26967 


FiB49 


0,62500 


FiB73 


0,65045 


FiB2 


-0,06679 


FiB26 


-0,13568 


FiB50 


0,87500 


FiB74 


0,28776 


FiB3 


0,04874 


FiB27 


-0,82054 


FiB51 


0,12500 


FiB75 


-0,82573 


FiB4 


-0,17504 


FiB28 


-0,21448 


FiB52 


0,37500 


FiB76 


-0,81912 


FiB5 


-0,78552 


FiB29 


-0,82496 


FiB53 


-0,37500 


FiB77 


-0,53909 


FiB6 


-0,17946 


FiB30 


0,95126 


FiB54 


-0,12500 


FiB78 


0,20640 


FiB7 


-0,86432 


FiB31 


-0,93321 


FiB55 


0,12500 


FiB79 


0,99219 


FiB8 


-0,73033 


FiB32 


-0,13834 


FiB56 


0,37500 


FiB80 


0,07463 


FiB9 


0,59955 


FiB33 


-0,37500 


FiB57 


0,62500 


FiB81 


0,92537 


FiB10 


-0,53776 


FiB34 


-0,12500 


FiB58 


0,87500 


FiB82 


0,00781 


FiB11 


-0,92427 


FiB35 


-0,87500 


FiB59 


0,12500 


FiB83 


0,79360 


FiB12 


-0,43088 


FiB36 


0,37500 


FiB60 


-0,62500 


FiB84 


-0,46091 


FiB13 


-0,21091 


FiB37 


-0,37500 


FiB61 


0,62500 


FiB85 


-0,18088 


FiB14 


-0,45640 


FiB38 


0,87500 


FiB62 


-0,12500 


FiB86 


-0,17427 


FiB15 


-0,74219 


FiB39 


0,12500 


FiB63 


-0,87500 


FiB87 


0,71224 


FiB16 


0,67537 


FiB40 


0,37500 


FiB64 


-0,62500 


FiB88 


0,34955 


FiB17 


0,32463 


FiB41 


0,62500 


FiB65 


0,11166 


FiB89 


-0,48033 


FiB18 


-0,25781 


FiB42 


0,87500 


FiB66 


-0,18321 


FiB90 


-0,11432 


FiB19 


-0,54360 


FiB43 


-0,87500 


FiB67 


0,20126 


FiB91 


-0,92946 


FiB20 


-0,78909 


FiB44 


-0,62500 


FiB68 


0,92504 


FiB92 


0,96448 


FiB21 


-0,56912 


FiB45 


0,62500 


FiB69 


0,03552 


FiB93 


0,07496 


FiB22 


-0,07573 


FiB46 


0,87500 


FiB70 


-0,07054 


FiB94 


0,79874 


FiB23 


-0,46224 


FiB47 


0,12500 


FiB71 


-0,88568 


FiB95 


-0,81679 


FiB24 


0,40045 


FiB48 


0,37500 


FiB72 


-0,51967 


FiB96 


0,88834 



Table P.50: Filler Set B FiSB48 phase values as a multiple of n radians 



FiSB48 


FiBI 


-0,74664 


FiB25 


-0,67802 


FiB49 


0.62500 


FiB73 


0,62500 


FiB97 


-0,00336 


FiB121 


-0,07198 


FiB2 


0,53305 


FiB26 


-0,89135 


FiB50 


0,87500 


FiB74 


-0,12500 


FiB98 


-0,78305 


FiBI 22 


0,64135 


FiB3 


0,53584 


FiB27 


-0,56750 


FiB51 


-0,87500 


FiB75 


-0,87500 


FiB99 


-0,28584 


FiBI 23 


0,81750 


FiB4 


-0,27109 


FiB28 


0,03426 


FiB52 


0,37500 


FiB76 


0,37500 


FiBlOO 


-0,97891 


FiBI 24 


0,71574 


FiB5 


0,28339 


FiB29 


-0,07169 


FiB53 


-0,37500 


FiB77 


0,62500 


FiBIOI 


0,96661 


FiBI 25 


-0,67831 


FiB6 


0,44134 


FiB30 


-0,38152 


FiB54 


-0,12500 


FiB78 


0,87500 


FiB102 


-0,69134 


FiBI 26 


0,13152 


FiB7 


-0,20086 


FiB31 


0,44789 


FiB55 


0,12500 


FiB79 


0,12500 


FiB103 


0,45086 


FiBI 27 


-0,19789 


FiB8 


0,52806 


FiB32 


0,73989 


FiB56 


-0,62500 


FiB80 


-0,62500 


FiB104 


0,22194 


FiBI 28 


0,01011 


FiB9 


-0,65020 


FiB33 


0,94715 


FiB57 


-0,37500 


FiB81 


-0,37500 


FiB105 


-0,09980 


FiBI 29 


0,30285 


FiBIO 


0,95551 


FiB34 


-0,92017 


FiB58 


0,87500 


FiB82 


-0,12500 


FiB106 


0,79449 


FiBI 30 


0,67017 


FiBII 


-0,62613 


FiB35 


0,23273 


FiB59 


0,12500 


FiB83 


0,12500 


FiB107 


0,87613 


FiB131 


0,01727 


FiBI 2 


0,51043 


FiB36 


-0,23953 


FiB60 


-0,62500 


FiB84 


-0,62500 


FiB108 


0,23957 


FiBI 32 


0,98953 


FiBI 3 


-0,76047 


FiB37 


0,48957 


FiB61 


-0,37500 


FiB85 


-0,37500 


FiB109 


0,01047 


FiBI 33 


0,76043 


FiB14 


0,76727 


FiB38 


-0,37387 


FiB62 


0,87500 


FiB86 


0,87500 


FiBIIO 


0,98273 


FiBI 34 


0,12387 


FiBI 5 


-0,07983 


FiB39 


0,04449 


FiB63 


-0,87500 


FiB87 


0,12500 


FiB1 11 


0,32983 


FiBI 35 


0,20551 


FiBI 6 


0,05285 


FiB40 


-0,34980 


FiB64 


-0,62500 


FiB88 


-0,62500 


FiB112 


0,69715 


FiBI 36 


-0,90020 


FiBI 7 


0,26011 


FiB41 


0,47194 


FiB65 


-0,37500 


FiB89 


-0,37500 


FiB113 


0,98989 


FiBI 37 


0,77806 


FiBI 8 


0,55211 


FiB42 


-0,79914 


FiB66 


0,87500 


FiB90 


0,87500 


FiB114 


-0,80211 


FiBI 38 


0,54914 


FiBI 9 


-0,61848 


FiB43 


0,55866 


FiB67 


0,12500 


FiB91 


-0,87500 


FiB115 


0,86848 


FiBI 39 


-0,30866 


FiB20 


-0,92831 


FiB44 


0,71661 


FiB68 


0,37500 


FiB92 


-0,62500 


FiB116 


-0,32169 


FiBI 40 


0,03339 


FiB21 


0,96574 


FiB45 


-0,72891 


FiB69 


0,62500 


FiB93 


0,62500 


FiB117 


0,28426 


FiB141 


-0,02109 


FiB22 


-0,43250 


FiB46 


0,46416 


FiB70 


-0,12500 


FiB94 


-0,12500 


FiB118 


0,18250 


FiBI 42 


-0,71416 


FiB23 


-0,10865 


FiB47 


0,46695 


FiB71 


-0,87500 


FiB95 


0,12500 


FiB119 


0,35865 


FiBI 43 


-0,21695 


FiB24 


-0,32198 


FiB48 


-0,25336 


FiB72 


0,37500 


FiB96 


0,37500 


FiB120 


-0,92802 


FiBI 44 


-0,99664 
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P.2.7 Linearization downlink zeroed set 

The numbering and use of this symbol set is defined in clauses 9.4.8.3.8 and P. 1.6. The linearization downlink zeroed 
set is a set of sub-carrier symbols whose magnitude is equal to zero. 
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Annex Q (informative): 
Change Requests 



The present document includes Change Requests as presented in table Q.l. Italic text indicates CRs that were already included into version V2.3.2 or are not applicable to the 
published version V2.4.2. 

Table Q.1 : List of Change Requests 



No 


CR 
vers. 


Version 


Clauses affected 


Title 


CR Status 


001 


APP 


V2.1.1 


28.4.4.1, 28.4.4.2, 28.4.4.3, 28.4.5.2 


Access point name index size 


EPT Approved 2000 


002 


APPi 


V2.3.2 


17.3.5, 17.3.6, 17.3.9, 18.2.4, 18.2.8, 20.2.4, 
20.3.4, 20.3.5.1, 22.1.2, 22.2.2.3, 22.2.2.5, 
22.2.2.7, 22.3.3.2.2, 22.3.3.2.7, 28.2.4.7, 28.2.6.2 
and annex A.I 


READY timer enhancement 


EPT approved 01 1121 


003 


APP 


V2.3.1 


29.5.4.2 


Text Character Encoding and Packing for 7, 8 and 16-bit Alphabet 


EPT approved 010305 


004 


APP 


V2.3.1 


29.4.3.9 


Error in see note reference 


EPT approved 010305 


005 


APP 


V2.3.1 


16.10.5 Table 167 


Clarification of Concurrent Channel in Class of IVIS 


EPT approved 010419 


006 


APP 


V2.3.1 


14.4.2 Figure 22 


Acceptance of D INFO in CC WAIT state 


EPT approved 010305 


007 


APP 


V2.3.1 


21.4.4.1 


Additional bit required for Security Information ("GCK Supported") 
for use in 392-7 


EPT approved 010419 


008 


APP 


V2.3.1 


28.2.4.5, 28.2.4.8, Figure 184 and Table 365 


IVIigration of Packet Data Mobile 


EPT approved 010419 


009 


REJ 


V2.3. 1 


28.2.5a 


IVIismatch of subscriber class 


Rejected 


010 


APPi2 


V2.3.1 


28.3.6, 28.4.1, 28.4.4.3, 28.4.5.10, 28.4.5.38 and 
28.4.5.45 


Correction of typographical errors and minor omissions 


EPT approved 010419 


011 


APPi 


V2.3.2 


28.2.4.4, 28.2.4.7, 28.4.4.9, 28.5 


Use of Immediate service change element on downlink 


EPT approved 01 11 21 


012 


REJ 


V2.3. 1 


16.4, 16.9, 16.10 


Sivfl/// Capabilities 


Withdrawn 


013 


REJ 


V2.3. 1 


21.4.4.1 


Additional bit required for Security Information ("Short GCK-VN") for 
use in 392-7 


Rejected 


014 


REJ 


V2.3. 1 


14.5.6.2 


PDU Priority for U-INFO 


Rejected 


015 


Comb 


V2.3.1 


11.3.4, 14.8.18 


New additional disconnect cause 


Combined with CR021 


016 


APP 


V2.3.1 


28.3.3.4 


Clarification to Packet Data MS type 


EPT approved 010629 


017 


APP 


V2.3.1 


annex C 


Correction to CRC calculation algorithm 


EPT approved 010629 


018 




V2.3. 1 






Not used 


019 


Comb 


V2.3.1 


11.3.4, 14.8.18 


New additional disconnect cause 


Combined with CR021 


020 


APP 


V2.3.2 


28.4.4.1 and 28.4.4.3 


Access point name index element on downlink 


EPT approved 011121 


021 


APP 


V2.3.1 


14.8.18 


New disconnect causes 


EPT approved 01 11 21 


022 


REJ 


V2.3. 1 


14.8.18 


New disconnect cause; Unknown number 


Withdrawn 


023 


REJ 


V2.3.2 


16 


Subscriber class 


Rejected 


024 


APPi2 


V2.3.2 


11.3.4, 14.5.1.1.5, 14.8.18 


DCOMP negotiation element 


EPT approved 01 11 21 
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No 


CR 
vers. 


Version 


Clauses affected 


Title 


CR Status 


025 


APP 


V2.3.2 


29.4.3.9 


SDS-TL Protocol IDs for encryption 


EPT approved 0201 30 


026 


APP 


V2.3.2 


18.5.17 


Note on Timeshare cell and Al encryption element 


EPT approved 01 11 21 


027 


APP 


V2.3.2 


16.4.11, 16.9.2.5.9, 16.10.7b, 16.10.7c, 17.3.1, 
17.3.2, 17.3.9, 20.3.5.4.1, 20.4.1.1.4, 20.2.4.29a 


Periodic distance reporting MM-STATUS PDU 


EPT approved 020130 


028 


APP 


V2.3.2 


28.3.3.4 


Packet data MS type 


EPT approved 030307 


029 


APP 


V2.3.2 


16.11.1.1 


Registration timer T351 


EPT approved 030307 


030 


APP 


V2.3.2 


14.6 


Call restoration timer T3G7 (P2MP) 


EPT approved 030307 


031 


APP 


V2.3.2 


29.5.2, 29.5.3 and 29.4.3.9 


Reservation of Protocol Identifiers for Immediate Text messaging 


EPT approved 030307 


032 


APP 


V2.3.2 


16.10.5 (Table 167) 


Errors in references to ETS 300 392-2 and EN 300 392-2 


EPT approved 030307 


033 


APP 


V2.3.2 


21.4.4.2 (Table 335) 


Errors in references to EN 300 392-2 and ETS/EN 300 392-7 


EPT approved 030307 


034 


APP 


V2.3.2 


29.4.3.9 


SDS-TL PID for OTAR should be for OTAK for End to End 
Encryption Key Delivery 


EPT approved 030307 


035 


APP 


V2.3.2 


29.5.4.1 


Mistake in the referred clause number 29.5.4.3 


EPT approved 030307 


036 


APP 


V2.3.2 


9.4.4.3.6 


Phase adjustment bits and n2 value 


EPT approved 030307 


037 


APP 


V2.3.2 


23.3.1.2.1 


Expand description of common SCCH configuration changes on 
BNCH 


EPT approved 030307 


038 


APP 


V2.3.2 


14.5.6b, 17.3.1, 17.3.2, 17.3.5, 17.3.6, 17.3.9, 
23.7.6, 28.2.4.4, 28.2.4.6, 28.2.4.7, 28.2.4.8 


Improve call set-up phase response for mobiles using Energy 
Economy Group 


EPT approved 030307 


039 


APP 


V2.3.2 


29.4.3.2 


Correction of the report source 


EPT approved 030307 


040 


APP 


V2.3.2 


29.3.3.6.3, 29.4.3.2 


Modification of the report reason "Destination not reachable, 
message stored by SwMI" 


EPT approved 030307 


041 


APP 


V2.3.2 


28.4.5.28 


Update to PCOMP negotiation table 


EPT approved 030307 


042 


APP 


V2.3.2 


28.4.5.9 


BSD compression and uncompressed data 


EPT approved 030307 


043 


APP 


V2.3.2 


28.3.5.4.2, 28.3.5.4.3, 28.3.5.4.4 


Clarification over data compression 


EPT approved 030307 


044 


APP 


V2.3.2 


14.8.34 


Typo in 14.8.34 Pre-coded status 


EPT approved 030307 


045 


APP 


V.2.3.2 


6.6.2.3 


Change in 6.6.2.3 Receiver performance at reference interference 
ratios 


EPT approved 030704 


046 


APP 


V2.3.2 


21.4.4.2 


Change of System Code in V+D to give 1 bit to DM0 for 2 additional 
values 


EPT approved 030708 


047 


REJ 


V2.3.2 


23.7.1.1 


Path loss parameter CI 


Withdrawn 


048 


APP 


V2.3.2 


18.3.4.7.5 


Error in reference to EN 300 392-7 


EPT approved 030708 


049 


APP 


V2.3.2 


annex K.2 


Change of Hong Kong country code 


EPT approved 030708 


050 


APP 


V2.3.2 


18.5.24 


TETRA System Time bits 


EPT approved 030708 


051 


APP 


V2.3.2 


3.1 


Further editorial corrections 


EPT approved 030708 


052 


APP 


V2.3.2 


29.4.3.9 


SDS-TL PID extension 


EPT approved 030708 


053 


REJ 


V2.3.2 


16.9.2.7, 16.10.51, 16.10.41 


Addition to ttie Air Interface in order to support Radio User 
Assignment (RUA) 


Width rawn 


054 


APP 


V2.3.2 


16.10.5,21.4.4.2 


TETRA standard version number 


EPT approved 030708 


101 


APP2 


V2.4.2 


18.3.4.6, 18.3.4.7, 19.3, 23.3.1.1, 23.3.1.2.1, 
23.5.6.1.1, Annex B.2 


Addition of a new system (BS) mode of operation 


EPT approved 050429 


102 


APP 


V2.4.2 


3.2, 29.5.4.1, Annex L 


Definition of how characters beyond that available with UCS-2 


EPT approved 040901 
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encoding is to be supported 




103 


APP 


V2.4.2 


29.5.1.2 


Clarification of 29.5.1.2 


EPT approved 040901 


104 


APP 


V2.4.2 


23.5.4.2.2, 23.5.4.2.3 


Movement of event labels 


EPT approved 040901 


105 


APP 


V2.4.2 


22.1.1 


Need for multiple advanced links 


EPT approved 050429 


106 


APP 


V2.4.2 


16.3.1.3.4, 17.3.6, 18.3.5.3.3, 20.2.4.24, 22.3.6, 
23.7.6, 23.7.7 


Energy economy mode inconsistencies between layers 


EPT approved 050429 


107 


APP 


V2.4.2 


16.10.48 


Periodic distance reporting "status downlink" value 


EPT approved 040901 


108 


APP 


V2.4.2 


16.10.5,21.4.4.2 


Erroneous implementation of CR054 


EPT approved 040901 


109 


APP 


V2.4.2 


29.5.7, Annex 1 


GPS coding scheme information element value application 


EPT approved 050429 


110 


APP 


V2.4.2 


18.5.24 


TETRA Network Time 


EPT approved 040901 


111 


APP 


V2.4.2 


2, 3.1, 3.2, 29.4.3.2, 29.4.3.9, 29.5.9 (new), 
29.5.10 (new), 29.5.1 1 (new). Annex N (new) 


Message with User Data Header 


EPT approved 040901 


112 


APP 


V2.4.2 


9.4.4.3.6, 14, 16, 18,21,28,29 


Indication of PDU type in the PDU definition tables 


EPT approved 040901 


113 


REJ 


V2.4.2 


16.10.30, 18.5.9 


LA range limitation due to EN 300 392-7 


Part 7 modified 


114 


APP 


V2.4.2 


11.3.3.5, 14.5.1.2.2 


Notice of imminent call disconnection 


EPT approved 040901 


115 


APP 


V2.4.2 


16.11.1.3 


T353 value editorial correction 


EPT approved 040901 


116 


APP 


V2.4.2 


14.6 


T310 value range alignment 


EPT approved 040901 


117 


APP 


V2.4.2 


Annex B.1 


T201 value on the assigned channel 


EPT approved 040901 


118 


APP 


V2.4.2 


Annex J 


Improvement of SDS-TL PID application form 


EPT approved 040901 


119 


REJ 


V2.4.2 


18.3.4.5.4, 18.3.4.5.5 


Cell dragging 


Withdrawn 


120 


APP 


V2.4.2 


8.2.3.2 


Typo in RM definition equation 


EPT approved 050429 


121 


APP 


V2.4.2 


2,3,29.4.3.9,29.5.12 


Location information transport protocol - additions to SDS-TL 


EPT approved 050429 


122 


SUB 


V2.4.2 


Annex (new) 


Location information transport protocol - transport method 
independent part 


Refer to TS 300 392-18-1 


123 


APP 


V2.4.2 


2, annex K 


Annex K update due to publication of ITU-T E.218 


EPT approved 050429 


124 


APP 


V2.4.2 


23.5.2.3.1 


Slot granting and not sending null PDU 


EPT approved 050429 


125 


APP 


V2.4.2 


5.4 


Missing part of equation (4) 


EPT approved 050429 


126 


APP 


V2.4.2 


23.5.2.3.2 


Wrong range 


EPT approved 050429 


127 


APP 


V2.4.2 


Many clauses in 17 to 23 and 28 to 29 


Addition of data priority feature for packet data 


EPT approved 050429 


128 


APP 


V2.4.2 


Annex J 


Overlapping allocation of PID values 


EPT approved 050429 


129 


APP 


V2.4.2 


28.4.5.31 


Length of protocol identity contents - clarification 


EPT approved 050429 


130 


APP 


V2.4.2 


Annex A. 1 


Counting downlink frames during reserved access on a multi-slot 
channel 


EPT approved 050429 


131 


APP 


V2.4.2 


21.5.2,23.5.4.3.3 


Channel allocation with "Up/downlink assigned" element set to OO2 


EPT approved 050429 


132 


APP 


V2.4.2 


28.3.4.2 


Editorial correction in clause 28.3.4.2 


EPT approved 050429 


133 


APP 


V2.4.2 


20.3.1 


Unacknowledged advance link on uplink 


EPT approved 050429 


134 


APP 


V2.4.2 


28.3.4.2 


Additional clarification in the use of the SN-RECONNECT PDU 


EPT approved 050429 


135 


APP 


V2.4.2 


28.2.4.4, 28.2.4.6, 28.2.4.7, 28.2.4.8 


Sleeping due to SNDCP state 


EPT approved 050429 


136 


APP 


V2.4.2 


22.3.4.2 


Unnecessary repetition of TL-CONNECT indication 


EPT approved 050429 


137 


APP 


V2.4.2 


23.5.4.2.1,28.2.4.7,28.3.4.6 


Correction of MS behaviour on receipt of of a group-addressed 
SN-END OF DATA PDU when the READY timer is active 


EPT approved 050429 


138 


APP 


V2.4.2 


15.3.1 


TNMM-STATUS response 


EPT approved 050429 
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139 


APP 


V2.4.2 


18.3.4.7, 18.3.4.7.1 


Conditions affecting the cell reselection method. 


EPT approved 050429 


140 


APP 


V2.4.2 


18.2.6, 18.3.5.4, 20.3.5.1.7, 28.3.4.7 


Incorrect use of TL-RELEASE indication primitive 


EPT approved 050429 


141 


APP 


V2.4.2 


28.3.4.2 


Clarification in the use of the SN RECONNECT PDU 


EPT approved 050429 


142 


REJ 


V2.4.2 


16.10.5 


GCK encryption support in Class of MS element 


Refer to EN 300 392-7 


143 


APP 


V2.4.2 


28.2.4.4, 28.2.4.7 


MS SNDCP can get stuck in READY state. 


EPT approved 050429 


144 


APP 


V2.4.2 


28.3.5.3.1, 28.3.5.3.2, 28.5.3.3.3, 28.3.5.4.1, 
28.4.4.14 


Inclusion of the PCOMP information element in SN-UNITDATA 
PDUs 


EPT approved 050429 


145 


APP 


V2.4.2 


E.2.1 


Conditional information elements in type 2 information element 


EPT approved 050429 


146 


APP 


V2.4.2 


29.3.2.1, 29.3.2.2, 29.3.2.8, 29.4.3.9, 29.5.5, 
29.5.6, 29.5.7, Annex 1 


GPS and generic location information systems 


EPT approved 050429 


147 


10 


V2.4.2 


Foreword, 1 


Contents of the scope 


TETRA approved 05061 5 


201 


11 


V2.5.2 


18.3.4.7.2, 28.2.4.4, 28.2.4.6, 28.3.4.2 


Clarification of Advanced Link Connection Status 


TETRA approved 060712 


202 


10 


V2.5.2 


16.9.2.1, 16.9.2.2, 16.9.2.7 


Definition of Security Related Information and Group Identity 
Security Related Information element 


TETRA approved 060712 


203 


10 


V2.5.2 


28.2.4.7, 28.2.5, 28.2.5a, 28.3.4.7 


Actions following receipt by the MS SNDCP of an MLE 
CONFIGURE indication announcing "loss of radio resources". 


TETRA approved 060712 


204 


10 


V2.5.2 


16.4.1.1, 16.10.42, 16.11.2, 16.11.2.1 


Actions following authentication failure 


TETRA approved 060712 


205 


10 


V2.5.1 


21.4.7,29.5.7,29.5.12.1, 1.1 


Identified editorial errors 


TETRA approved 060712 


206 


10 


V2.5.1 


Annex M 


Errors in table numbering mapping for clause 18 


TETRA approved 060712 


207 


REJ 


V2.5.2 




LIP usage during temporary disable 


Widthrown 


208 


10 


V2.5.2 


28.2.4.4, 28.2.6.4, 28.3.4.4 


Use of SN-RECONNECT and SERVICE CHANGE timer 


TETRA approved 060712 


209 


10 


V2.5.2 


16.10.5,21.4.4.2 


Version number 


TETRA approved 060712 


210 


10 


V2.5.2 


18.3.4.5.1, 18.3.4.5.6b, 18.3.4.5.7, 18.3.4.7, 
18.3.4.7.1 


Ouick handover in tunnels and similar conditions 


TETRA approved 060712 


211 


10 


V2.5.2 


18.3.5.3.3,23.7.6,23.7.7 


Additional clarification of the use of Energy Economy Groups during 
call set-up phase 


TETRA approved 060712 


212 


10 


V2.5.2 


Annex CR requests 


Alignment of TS 100 392-2 version with EN 300 392-7 version 
V2.3.1 


For information 


213 


10 


V2.5.2 


29.5.9.3, 29.5.10.3, 29.5.1 1 .3 new, 29.5.1 1 .4 to 
29.5.11.10 


Time stamp used and Text encoding method information element 
lengths 


TETRA approved 060712 


216 


10 


V2.5.2 


6.4.2.2.1, 6.4.2.2.2, 6.4.6.2, 6.4.7 


-36 dBm requirement clarification 


TETRA approved 060712 


217 


10 


V2.5.2 


14.5.6.6, 16.3.1.1, 16.4, 16.4.1.1, 16.4.1.2, 16.4.2, 
17.3.1, 17.3.2, 17.3.3, 17.3.4, 17.3.5, 17.3.6, 
17.3.9, 18.2.2, 18.2.3, 18.3.5.4, 28.2.4.1, 28.2.5, 
28.2.5b 


Protocol model for temporary disabling 


TETRA approved 060712 


218 


02 


V2.5.2 


New annex "0" (not included 16.5.2006) 


Addition of air - ground - air service 


TETRA approved 060712 


- 


- 


V2.5.2 


Many 


Additions due to High Speed Data 


TETRA approved 


301 


11 


V3.1.1 


18.3.4.7 (including 18.3.4.7.0 (new heading), 
18.3.4.7.1, 18.3.4.7.4, 18.3.4.7.5(renamed) and 
18.3.4.7.6(renamed)) 


Clarification to type 1 and type 2 cell reselection 


WG3 approved 070423 


302 


11 


V3.1.1 


6.7.1.1 


Modulation accuracy for 0AM 


WG3 approved 070109 


303 


10 


V3.1.1 


16.4.1.1, 16.4.1.2, 16.4.2, 16.4.3 


MS response to unexpected D-LOCATION UPDATE REJECT PDU 


WG3 approved 070320 


304 


01 


V3.2.0 


30 


Updated MEX layer 


WG3 approved 070821 
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305 


10 


V3.2.1 


16.10.5,21.4.4.2 


Version number update 


WG3 approved 071004 


306 


10 


V3.2.1 


6.4.9.3 


Correction of tlie wideband noise limits 50 WHz QAIVI 


WG3 approved 071004 


307 


10 


V3.2.1 


8.2.3.4.2 


Clarification to the turbo interleaving 


WG3 approved 071004 


308 


10 


V3.2.1 


18.3.4.5.7 


Use of cells with reserved system code 


WG3 approved 071 127 


309 


20 


V3.2.1 


2, 3, 28, 28.1, 28.2.3.2, 28.2.4.7, 28.3.3, 28.3.3.2, 
28.3.4.2, 28.3.5.5.4, 28.3.6, 28.4.4.2, 28.4.5.3, 
28.4.5.11a, 28.4.5.30b, 28.4.5.31a, 28.4.5.31b, 
28.4.5.31d, 28.4.5.31e, 28.4.5.35c, 30.1, 30.4.4 


SNDCP updates 


WG3 approved 080624 


310 


10 


V3.2.1 


14.2.7.6, 14.5.5.2, 17.3.9, 18.3.5.3.1 


Concerning the use of advanced links for SDSs 


WG3 approved 080408 


311 


10 


V3.2.1 


2,3,29.4.3.9,29.5.13 


PlDforNAP 


WG3 approved 080226 


312 


10 


V3.2.1 


29.4.3.2 


Too long SDS messages 


WG3 approved 080310 


313 


REJ 


V3.2. 1 


21.4.31 


NULL-PDU and change of cipher key 




314 


10 


V3.2.1 


1 1 .2, 1 1 .3.3.1 , 1 1 .3.3.2, 1 1 .3.3.4, 1 1 .3.3.5, 
1 1 .3.3.6, 1 1 .3.3.7, 1 1 .3.3.8, 1 1 .3.3.9, 1 1 .3.4, 
14.5.1.2.2, 14.5.2.2.2 


Limited group coverage 


WG3 approved 080408 


315 


10 


V3.2.1 


29.5.4.1 


Recommended character sets and names of those 


WG3 approved 080226 


316 


10 


V3.2.1 


28.3.5.1 


Effect of the TL-SDU windowing mechanism to the SNDCP 
behavior. 


WG3 approved 080624 


317 


01 


V3.2.2 


3.2, 4.10, 5.12, 6.4.1.2, 6.7.2.1, 9.4.9.2, 14.2.3, 
16.4.7.3, 16.10.10a, 18.3.4.7.3, 18.2.4.7.5, 
18.3.4.9.5, 18.4.1.4.6, 20.2.4.50, 21.5.2b, 22.2.2.1, 
22.2.2.8a, 23.1.2.1.3, 23.5.2.4.1, 23.5.4.2.3, 
23.8.3.2, 28.2.3.2, 28.2.4.4, 28.3.3, 28.3.3.3, 
28.3.6, 28.3.9, 28.4.5.3, 28.4.5.11a, 28.4.5.19d, 
28.4.5.31a, 30.2.3.2, 30.4.4.7, 30.4.4.22, 30.3.7.3, 
E.1.1, E.2.1,0.2 


Editorial corrections 


For information 


318 


10 


V3.2.1 


16.10.10a 


Air to ground support indication 


WG3 approved 080624 
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